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.

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.