Category: GDPR

Using Your Technical Authors as Strategists, Planners, and Consultants

Many businesses still misunderstand what a technical author can deliver.
They see a writer — not a strategist. A formatter, not a planner. A proofreader — not a consultant.

When used correctly, technical authors bring structure, compliance, and clarity to every stage of the information lifecycle. They turn documentation into a strategic enabler that supports ISO certification, ITSM frameworks, and information governance.

I didn’t gain this experience by taking on low-level contracts.
I built it by accepting complex, high-expectation assignments that demanded expertise — not routine.
Projects governed by ISO 27001, ISO 9001, PCI DSS, GDPR, and ITIL-aligned IT Service Management (ITSM) systems, where documentation wasn’t an afterthought, but a control in its own right.

From Document Writer to Information Strategist

Early in my career, I learned that a procedure is only as good as the system it supports.
As I advanced, I began designing those systems — integrating documentation with SharePoint, Asite, and enterprise knowledge bases to create traceable, auditable, and user-friendly environments.

That shift — from producing documents to architecting knowledge — is what separates an average writer from a documentation strategist.

Embedding ISO and Regulatory Frameworks

ISO 9001 — Quality Management

ISO 9001 demands consistency, clarity, and control. Technical authors design document templates, review workflows, and approval paths that prove process reliability. Well-structured documentation becomes part of the organisation’s quality evidence during internal and external audits.

ISO 27001 — Information Security

Under ISO 27001, documentation itself is a security control. Policies, risk registers, and incident procedures must align with the ISMS.
Experienced authors ensure classification, access permissions, and audit records are built into the documentation framework, not bolted on afterwards.

PCI DSS — Payment Card Security

PCI DSS requires clear operational documentation to evidence data protection. Authors provide traceable, reviewed, and controlled documents that survive audit scrutiny and demonstrate compliance with strict data-handling protocols.

GDPR — Data Protection and Privacy

GDPR compliance relies on transparency and accountability. Technical authors transform complex regulation into usable, plain-English policies: data-retention schedules, subject-access request processes, and breach-notification guides that staff can actually understand and apply.

Aligning Documentation with ITIL and ITSM

In IT environments, documentation underpins every ITIL and IT Service Management process:

      • Incident Management: Documenting escalation paths and resolution steps for service continuity.
      • Change Management: Recording change requests, approvals, and rollback plans to ensure traceability.
      • Problem Management: Capturing known errors and lessons learned to improve service quality.
      • Configuration & Asset Management: Maintaining controlled, versioned records of infrastructure and applications.
      • Service Continuity: Creating and maintaining recovery and resilience documentation aligned with ISO 22301.

A technical author versed in ITIL ensures that every process has the appropriate governance and documentation frameworks to meet compliance, audit, and service-delivery standards.

Aligning with Information Management and Document Control

Technical authors sit at the crossroads of Information Management (IM) and Document Control (DC) — translating policies into practice and ensuring that every piece of information has purpose, ownership, and lifecycle control.

      • In Information Management, authors define how data becomes information — creating naming conventions, metadata structures, taxonomies, and templates that keep repositories usable and compliant.
      • In Document Control, they understand versioning, approval hierarchies, baselining, and retention schedules — the mechanisms that give documentation its legal and operational validity.
      • Together, these functions ensure that knowledge doesn’t just exist, but is managed, retrievable, and auditable across departments, projects, and systems.

Where Information Management provides governance and Document Control enforces consistency, technical authors provide the structure and clarity that make both work.

The Modern Technical Author’s Toolkit

Today’s senior technical author is:

      • A strategist, aligning documentation with ISO, GDPR, ITIL, and corporate frameworks.
      • A planner, integrating documentation into project and service lifecycles.
      • A consultant, advising leadership on governance, information management, and document control.
      • A knowledge manager, ensuring content remains accurate, traceable, and secure.
      • A systems designer, configuring SharePoint or Asite to automate metadata, version control, and review cycles.

When you position your technical authors at this level, you gain more than documentation — you gain information assurance.

Experience Earned Through Expertise

Every project I’ve worked on — from ISO 9001 audits to 27001 ISMS documentation, from GDPR compliance to ITIL process alignment — has reinforced one truth:
Documentation is infrastructure.

It connects people, process, and technology.
It demonstrates governance and compliance.
And when managed properly, it becomes the backbone of every successful audit and transformation.

Final Thought

Technical authors who have grown through challenging environments understand how documentation supports the wider information ecosystem — policy, process, system, and control.

They close the gaps between communication and compliance, between information and evidence.

So before assigning your technical authors to “tidy up templates,” ask instead:

“Can this person help us align ISO, ITIL, and Information Management requirements into a single, coherent documentation strategy?”

If the answer is yes, you’re not hiring a writer.
You’re engaging a strategic partner in governance, compliance, and service excellence.

Technical Writing | General Data Protection Regulations

GDPR

On the 25th May 2018, the new General Data Protection Regulations (GDPR) came into force.

Companies outside the EU

If your Company actively trades within the EU and stores, processes or shares EU citizens’ data, then GDPR does apply to you.

Compliance and documentation

One of the primary rules is that under GDPR Process activities MUST be documented.

Companies are required to maintain a set of Policy, Process and Plan (PPP) documentation to ensure you have evidence to support your claims should the ICO investigate any complaint or breach of data.

Note that the Information Commissioners Office (ICO) could demand to see the written documents

What do you need to consider?

As a technical writer, with experience writing compliance documentation, what can I tell you?

If you are still struggling to start

My Blogs are clear, writing one document, when there is a substantial list to be completed from scratch to sign off is a lengthy process. Even if your department has documents that can be reused, it will still take a long time. Compliance projects are manually intensive and documenting GDPR will need dedicated resources.

My experience could be necessary to help you write and manage those documents. The sooner you contact me, the sooner we can start the road to compliance.

  • Create a standard template with – Statement, In Scope, Version Control, Change History, Distribution Lists, Roles and Responsibilities
  • All PPPs must adhere to GDPR – include in the document ‘The purpose of the document’, ‘The Scope’ and add a list of the GDPR compliances relevant to the PPP you are writing and explain the WHY the company are complying along with the HOW the company will comply.
  • The documentation must be relevant to your business. Generic documentation outlining a PPP will NOT suffice
  • Complete the documentation – do not start and leave a document incomplete then sign off; an incomplete document could fail a Compliance Audit
  • Maintain the detail – do not half explain a process or policy
  • Structure the documentation to avoid duplicating information over several documents
  • That the documentation may need to be ISO 27001 compliant
Does Your GDPR Project need documentationClick To Tweet

 

Hire a Technical Author sooner, rather than later

Documentation projects rarely fail at the writing stage—they fail during planning. Poor scoping, unrealistic timelines, and lack of technical author input lead to delays, rising costs, and incomplete deliverables. Here’s how to avoid it.

Tweet
Pin
Share
0 Shares

Documentation project planning

As a technical writer with over twenty years of experience, I have seen project managers repeat the same mistakes across multiple projects. The root cause points to poor documentation planning. It is a problem that often goes unnoticed until a professional steps in and identifies it.

If you have delivered a project involving PCI, GDPR, ISO27001, ITIL, or policy and process documentation, ask yourself:

Did the project deliver all the required documentation?
If not, do you know why?

In my experience, the failure begins in the planning stages.

The First Mistake: Not Consulting a Technical Author Early

Did you speak to a technical author for a realistic appraisal?

If the answer is no, there lies your answer.

Managers treat documentation as a downstream activity. Something to complete once systems, processes, or controls are in place.

That assumption is wrong. Documentation is a structured discipline involving:

      • discovery
      • analysis
      • stakeholder engagement
      • controlled writing
      • review cycles
      • approval workflows

Without this understanding, planning becomes guesswork.

The Second Mistake: Underestimating Time and Budget

Another common issue:

The budget is short, and the timelines are optimistic.

Project managers frequently underestimate the effort required to produce controlled documentation.

A simple question often arises:

“How long does it take to write a document?”

The honest answer is:

“It depends.”

Because writing is only one part of the process.

What Actually Takes Time in Documentation Projects

For a typical documentation project, the effort is distributed across:

      • Information gathering
      • SME interviews
      • Conflicting opinions and interpretations
      • Writing and structuring
      • Multiple review stages
      • Amendments and rework
      • Final approval and sign-off

Here’s a realistic outcome to consider:

      • 30-page process document
      • 3+ Visio diagrams (10–30 steps each)
      • 3+ process narratives
      • 2+ appendices

Expected effort: 8–12 weeks before review.

That is one document.

Scaling the Problem: Compliance Projects

Compliance frameworks significantly increase the scope.

If starting from scratch:

      • 60+ documents is not unusual
      • 12–18 months of work is typical
      • 24 months is a safer estimate

If documentation already exists, fragmented across drives, emails, and legacy systems: Do not expect timelines to reduce; the first phase becomes:

      • consolidation
      • standardisation
      • validation

This alone can take months.

The Knowledge Gap in Planning

A major contributor to failure is a lack of understanding of:

      • The difference between a policy, a process, and plan
      • The document lifecycle (draft → review → approval → maintenance)
      • The complexity of controlled documentation environments

Delays are inevitable when managers cannot understand these fundamentals during planning.

Why do documentation projects fail?

Documentation projects typically fail due to:

      • Poor planning
      • Lack of documentation expertise
      • Unrealistic timelines
      • Insufficient budget
      • No defined ownership or review structure

Why Documentation Projects Succeed

Successful projects have:

      • Early involvement of a technical writer
      • Clear understanding of the documentation lifecycle
      • Realistic timelines based on effort
      • Defined ownership and governance
      • Structured review and approval processes

Hire a Technical Writer at the Start — Not the End

A common mistake is hiring a technical writer when:

      • deadlines are approaching
      • Documentation is incomplete
      • Exhausted budgets
      • At that point, recovery is expensive.

A technical writer engaged at the start can:

      • Identify risks early
      • define a realistic scope
      • structure documentation outputs
      • manage stakeholder expectations
      • prevent rework

Resourcing Considerations

Technical writers require:

      • Time to understand the project
      • Training on tools and environments
      • Access to SMEs
      • Availability for review cycles

You must also account for:

      • holidays
      • illness
      • unplanned absences
      • staff turnover
      • These are not exceptions. They are normal project variables.

Quality vs. Quantity: Use Prioritisation

When timelines are tight, prioritise deliveries using the MoSCoW Method:

      • Must have
      • Should have
      • Could have
      • Won’t have (this time)

Or classify documents as:

      • Required
      • Nice to have
      • Not important

Focus on delivering usable, controlled documentation, not volume.

Additional Planning Factors Often Ignored

      • Travel: Will the technical writer need to travel?
      • What can you reuse?
      • Review structure: Who reviews and who signs off?
      • Scope changes: How to control expansion?

Final Thought

When your project requires documentation, why is so much of the budget allocated to everything except documentation?

Documentation is not an afterthought. It is the mechanism that explains, controls, and sustains your operations.

Remove it—or underfund it—and the cost will surface later.

Usually, when it matters most.