Eighteen years of practitioner observation on why governance programs consistently fail to leverage the people who understand control documentation best — and why that is changing.
In eighteen years across enterprise, federal, financial services, healthcare, and technology documentation programs, I have watched a predictable pattern repeat. A GRC program gets serious about compliance. An internal team writes policies. An external auditor identifies that the policies don't accurately describe what the organization actually does. The CISO is frustrated. The audit findings are remediated — poorly, quickly, under pressure — and the same findings appear in the next audit cycle. The organization hires more compliance analysts. The documentation continues to fail auditors.
The pattern's resolution, when it happens, is almost always the same: a technical writer gets involved. Not a policy analyst writing from regulatory text. Not a compliance manager writing from audit findings. A technical writer — someone trained to translate complex operational reality into clear, accurate, structured documentation — who sits with the engineers, the security architects, and the system administrators, and writes what actually happens.
What strikes me about this pattern is not that technical writers solve the problem. It's that organizations are surprised when they do.
A control narrative is a technical document. Writing an accurate ISO 27001 control narrative for access management requires understanding: how identity is provisioned and deprovisioned in the specific environment being documented, what the actual approval workflow is for access requests, how privileged access is managed differently from standard access, what monitoring exists for access anomalies, and how that monitoring is reviewed, by whom, at what cadence. This is not a policy question. It is a systems question — and answering it accurately requires the same skills that technical writers apply to documenting any complex system: sustained attention to operational reality, structured elicitation from subject matter experts, and the ability to translate what engineers describe into prose that auditors can evaluate.
What most GRC programs produce instead is a different kind of document: a control narrative written from regulatory guidance rather than operational reality. The narrative describes what the organization's access management program should look like, referencing the framework's requirements — which is not what auditors evaluate. Auditors evaluate what the organization's access management program actually looks like, and whether the documentation describes it accurately. A control narrative that describes requirements rather than implementation fails both tests.
"The skill that makes technical writers effective at documentation — sustained attention to operational reality rather than idealized description — is exactly the skill that makes GRC documentation defensible to auditors."
The underestimation of technical writers in GRC contexts persists for three reasons that I have seen operating consistently across my career.
First, GRC programs are staffed by people whose professional identity is compliance, not communication. The mental model of the compliance team is that compliance is the domain expertise, and documentation is a supporting activity that anyone literate can perform. This mental model is wrong — but it is deeply embedded in how GRC programs are structured, staffed, and resourced. The consequence is that organizations consistently assign their most consequential documentation to the people least trained to produce it.
Second, the cost of documentation failure is invisible until audit. Poor control documentation doesn't break the control. The access management program works the same way whether its documentation is accurate or aspirational. The failure mode surfaces only when an auditor evaluates the documentation against operational reality — which may be months or years after the documentation was written. This long feedback loop means that organizations consistently underinvest in documentation quality because the consequences of poor documentation quality are deferred and opaque.
Third, technical writing is not recognized as a regulated-environment specialty in most organizations. Technical writers who develop expertise in ISMS documentation, FedRAMP SSPs, EU AI Act technical documentation, or medical device IFUs are practicing a specialized discipline — but most organizations don't recognize this specialization in their job architecture, compensation frameworks, or career development programs. The expertise exists in the market; organizations simply don't know how to identify and value it.
The regulatory environment of 2026 is changing the calculus in ways that will, I believe, eventually force a reckoning with the undervaluation of technical writing in GRC contexts.
EU AI Act Annex IV requires technical documentation of a specificity that policy teams writing from regulatory text will consistently fail to produce accurately. The documentation requirement is not "describe your AI governance program" — it is "describe the training data characteristics, including the data acquisition and selection methodology, cleaning processes, labeling methods, and how data was evaluated for bias." Writing that accurately, in a form that a market surveillance authority can verify against the actual data governance practices, requires the same skills as writing accurate technical documentation for any complex system.
FedRAMP's OSCAL program is requiring that SSPs be produced in structured, machine-readable formats — formats that are much closer to structured authoring (DITA/XML, JSON, XML) than to word processing. The practitioners best positioned to produce OSCAL-format SSPs are technical writers with structured authoring backgrounds, not compliance analysts with word processing backgrounds.
ISO 27001:2022's expanded control set, combined with increasingly specific surveillance audit expectations, is producing audit findings in organizations whose control documentation was adequate for 2018 examination expectations but is not adequate for 2026 examination expectations. Closing those gaps requires the same capability that closed them initially: technical writers who understand both the control framework and the operational reality they are documenting.
The argument I have been making for eighteen years, and that I am making more explicitly here: governance documentation is not an administrative function. It is a discipline with its own methodology, its own expertise requirements, and its own professional standards. Organizations that staff governance documentation programs with compliance analysts who happen to write, rather than with technical writers who happen to understand compliance, will consistently produce documentation that fails auditors — and will be surprised every time.
The most defensible GRC documentation programs I have seen — at PwC, at TransUnion, at the U.S. Department of Justice, at Philips — shared a common characteristic: they were built by practitioners who understood that writing accurate technical documentation of complex governance systems is a technical discipline, not a compliance discipline. The compliance expertise is necessary; it is not sufficient. The technical writing expertise is what makes the difference between documentation that describes governance and documentation that is governance.