Many compliance programs begin with a deadline. A customer asks for a certificate or a report, a project starts, and a set of policies and procedures is written in a few weeks. The audit passes. A year later the same controls fail, because nobody operated them in between.
The documents described a company that did not exist. Governance that lasts is built the other way round: from how the company works, with documentation that records it. This article describes that approach and its limits.
Why documentation sprints fail the next audit
A first audit leans toward design. Is there a policy, is there a procedure, does the control exist. A template-based document set can satisfy much of that. Later audits test operation over a period: surveillance audits for ISO/IEC 27001, and the whole examination period for a SOC 2 Type 2 report.
This is where sprint-written controls break. The access review procedure says quarterly, and one review was done. The change policy requires an advisory board that has never met, because engineering deploys through pull requests. The auditor samples, finds the gap, and raises a nonconformity or an exception.
The deeper cost is cultural. Staff learn to see security governance as fiction maintained for outsiders. Once that happens, real risks stop being raised through it.
Start from how the company operates
Before writing a control, find the process that already runs. Most companies control change, access and suppliers in some form, even if nobody calls it a control.
Take change management. If every production change goes through a pull request with a required reviewer, automated checks and a pipeline deployment, that is a change control. Write it down as it is:
All changes to production code are made through pull requests. Branch protection requires approval from one engineer other than the author, and passing checks, before merge. Deployments run only from the main branch through the CI/CD pipeline.
That statement is true, testable and leaves records automatically. Compare it with a borrowed procedure that requires signed change request forms. The first will pass every sample. The second will fail the first time someone is busy.
Where the existing process has a real gap, such as emergency changes that bypass review, fix the process with the team that owns it and then document the result. A control should never describe an intention. It should say who does what, on which systems, how often, and what record it leaves. If any of the four is missing, it cannot be tested.
One control library mapped to several frameworks
Frameworks overlap heavily. ISO/IEC 27001:2022, SOC 2 and PCI DSS all expect access to be approved, reviewed and removed, changes to be controlled, logs to be kept, incidents to be handled and suppliers to be assessed. So do the security provisions of regional and sector requirements, such as GDPR, the DPDP Act or SEBI CSCRF.
Running each framework as a separate project produces several descriptions of the same activity, which then drift apart. The alternative is one library of your own controls, each mapped to every requirement it supports. The control is operated once, evidenced once and reported many times. The list of compliance frameworks a company answers to can then grow without the control set growing at the same rate.
Three cautions apply:
- Operate to the strictest requirement. Where frameworks differ in frequency or depth, PCI DSS is often the most prescriptive. Either run the control at that level everywhere, or state clearly that the stricter version applies to a defined scope such as the cardholder data environment.
- Keep scope explicit. A control that applies to one product or environment should say so. Unclear scope is a common source of audit findings.
- Do not force mappings. Some requirements are specific, such as individual rights under privacy law or a regulator's reporting format. They need their own controls, and a stretched mapping will not survive scrutiny.
Whether the library lives in a spreadsheet or a GRC platform matters less than having one source. A tool earns its place once the number of controls, owners and frameworks makes the spreadsheet unreliable.
Evidence as a by-product of operations
If evidence has to be created for the audit, the control is probably not running as described. Well-designed controls leave records in the systems where the work happens.
| Control | Record produced by normal work | Collection |
|---|---|---|
| Change control | Pull requests with reviewer, checks and merge history | Scheduled query of all merged production changes |
| Joiners, movers and leavers | HR tickets and identity provider provisioning logs | Scheduled list of joiners and leavers with timestamps |
| Access review | Export of accounts and roles, reviewer decisions, removal tickets | Each review cycle, stored with sign-off |
| Backup and restore | Backup job logs and restore test records | Job summary on a schedule, one record per restore test |
| Vulnerability remediation | Scanner results and remediation tickets | Scheduled snapshot of open items against due dates |
| Supplier assessment | Completed reviews and contract clauses in the supplier register | At onboarding and at each review date |
Collect on a schedule, not before the audit. Auditors who test operation ask for a population, such as all production changes in the period, and choose samples from it. A population produced by a query is strong evidence in itself. Screenshots assembled the week before fieldwork are weak evidence, and the rush to produce them hides the controls that lapsed.
Scheduled collection also acts as monitoring. If this month's export shows merges without review, the owner learns of it this month, corrects it and records the exception. Found by the auditor much later, the same gap covers most of the period.
Risk registers, owners and metrics that drive decisions
A register that informs decisions
A register kept for the auditor is easy to recognize. It lists generic risks such as "malware" or "data breach", each scored medium, with no owner and an update date just before the audit. It informs nothing.
A working register is shorter and more specific. Each entry has:
- a concrete scenario, for example "loss of the production database through compromise of a CI/CD credential with write access"
- an owner with authority over the affected system or budget
- a treatment decision (reduce, accept, transfer or avoid) with the actions and dates that follow
- a review date, and a trigger for early review such as a significant change or an incident
The test is whether the register changes decisions. It should be where a security investment is justified and where a risk acceptance is signed by someone entitled to accept it. Findings from penetration tests, incidents and third-party risk reviews should land there too. Under ISO/IEC 27001, risk treatment justifies the controls in the Statement of Applicability, so a hollow register weakens everything built on it.
Control ownership outside the security team
The security team operates few of the controls it is audited on. HR runs screening, onboarding and offboarding. Engineering runs change control and secure development. IT runs device management and backups. Procurement and legal run supplier contracts.
Assign each control to the person who manages the process, and agree the wording with them. The security or GRC function then has a different job: maintain the library and mappings, run the collection schedule, test controls independently and report status. Control performance should appear in the same management reviews as other operational commitments.
Metrics worth keeping
A small set of measures shows whether governance is functioning. Each is a count or a list from your own records, reviewed as a trend.
- Overdue actions. Corrective actions, audit findings and risk treatments past their due date, by owner.
- Control test failures. Controls that failed internal testing or a scheduled evidence collection, and how long correction took.
- Exceptions and their expiry. Policy exceptions and risk acceptances in force, who approved each, and which have expired without review.
- Register currency. Risks past their review date.
Avoid measures that reward documentation, such as the number of policies published or the share of controls marked implemented. They rise without any change in how the company operates.
What a readiness partner can and cannot do
Outside help is useful for gap assessment, control design, framework mapping, internal audit, interview preparation and support during the audit. Compliance readiness work shortens the path and avoids common mistakes.
It does not produce the certificate or the report. An ISO/IEC 27001 certificate is issued by an accredited certification body. A SOC 2 report is issued by a licensed CPA firm. PCI DSS compliance is validated by a Qualified Security Assessor or through self-assessment, depending on the entity. A consultant who designed the controls cannot independently audit them, and no consultant can promise an audit outcome.
A partner also cannot operate your controls indefinitely without recreating the original problem. Good readiness work is measured by whether the controls keep running after the consultants leave.
Where to start
- Pick three processes that already run well, such as change, access and backup, and write control statements that match them exactly.
- Put all controls in one library and map each to every framework requirement it supports.
- For each control, name the record it leaves and set a collection schedule with an owner.
- Rewrite the top risks as concrete scenarios with owners, treatment decisions and review dates.
- Start a regular review of overdue actions, failed control tests and expiring exceptions.