Why compliance evidence deserves better than a shared drive — and what storing it properly actually looks like
Ask most compliance officers where their organisation’s compliance documents live and the answer is rarely reassuring. A shared drive that everyone in the department can access. An email folder maintained by whoever currently holds the compliance role. A SharePoint site set up years ago with permissions nobody has reviewed since. A collection of PDFs in a generic cloud storage folder passed around on a link that nobody can account for.
The irony is pointed. The documents that demonstrate an organisation’s commitment to security, access control, and information governance are themselves stored with almost none of those things applied to them. The evidence that would be produced in a regulatory audit or an incident investigation — the records that prove the organisation does what it says it does — sits in locations that are inadequately controlled, inadequately audited, and in some cases inadequately protected against the very risks the compliance programme is supposed to address.
This is not a niche problem. It affects almost every regulated organisation, in every sector, in every jurisdiction. And it matters more than most compliance teams have yet recognised — because regulators are increasingly interested not just in what compliance evidence exists, but in how it has been stored, who has accessed it, and whether its integrity can be demonstrated.
What Compliance Documents Actually Are
Compliance documentation covers an enormous range of material depending on the sector and regulatory framework, but the underlying categories are broadly consistent.
- Risk assessments and management records — Documented analysis of what risks the organisation faces, how they have been evaluated, and what controls are in place. Often the most sensitive documents in the compliance portfolio because they candidly identify vulnerabilities.
- Incident records — Detailed accounts of security incidents, operational failures, and near-misses — what happened, when, how it was discovered, how it was contained, and what remediation was undertaken. Most major frameworks require these to be produced to regulators within defined timelines.
- Third-party and supply chain records — Contracts, due diligence assessments, access logs, and incident histories for every external party with access to systems or data. Supply chain oversight is an explicit requirement of an increasing number of frameworks.
- Access control and identity records — Documentation of who has access to what, on what basis, reviewed when, and revoked when. The audit trail of access decisions is the foundation of demonstrating that controls work in practice, not just in policy.
- Board and governance records — Minutes, resolutions, and documented decisions at the governance level, establishing that security is being actively managed at the right level of the organisation.
- Regulatory correspondence — Communications with regulators, supervisory authorities, and auditors. Frequently containing information about the organisation’s vulnerabilities or compliance gaps — and almost never stored with controls appropriate to their sensitivity.
- Certifications and audit reports — Penetration test results, vulnerability assessments, certification evidence, and third-party audit reports. A penetration test report that identifies every significant weakness in the organisation’s security posture is particularly sensitive — and is frequently stored in a shared folder accessible to the entire IT team.
Why Where You Store Them Matters
The question of where compliance documents are stored is not just an administrative one. It has direct consequences for regulatory compliance, legal defensibility, and the practical integrity of the compliance programme itself.
Evidence integrity
An increasing number of regulatory frameworks explicitly or implicitly require that compliance evidence be stored in a way that preserves its integrity. A document stored in a shared drive that multiple people can edit is not demonstrably unaltered. A record maintained in a generic email folder has no reliable chain of custody. An audit report saved in broadly shared cloud storage cannot be shown to have remained unchanged since it was produced. The evidence that is supposed to demonstrate compliance is itself non-compliant in how it is stored.
Access control
Compliance documents frequently contain information that should be tightly restricted. Yet they are routinely stored in locations where access is controlled at the folder level rather than the document level, where permissions have not been reviewed in years, and where there is no audit trail of who has accessed what. A penetration test report accessible to every member of the IT team is an information security risk in its own right. The controls the document describes are not being applied to the document itself.
Chain of custody
When a regulator requests compliance evidence, they are not just interested in what the documents say. They are interested in whether the documents are trustworthy. Can the organisation demonstrate that an incident record was created at the time of the incident and has not been modified since? Can it show that a risk assessment reflects the organisation’s actual position when it was produced? A document stored in a shared drive, editable by multiple people, with no version history and no access log, cannot answer these questions satisfactorily. Evidence whose integrity cannot be demonstrated is evidence whose value is significantly diminished.
External sharing
Compliance evidence regularly needs to be shared with external parties — regulators, auditors, legal counsel, insurers, certification bodies. The standard approach — emailing documents as attachments or sharing a folder link — means the organisation loses control the moment documents leave. There is no record of what was accessed and when. There is no mechanism to revoke access when the review is complete. And the sharing event itself is not recorded in a form that can be produced if questions subsequently arise.
What the Frameworks Actually Require
While the specific requirements vary by framework and jurisdiction, the common thread is consistent: evidence must exist, must be accurate, must be producible on demand, and increasingly must demonstrate that it has been properly controlled and maintained. The following frameworks are representative of what regulated organisations across different sectors and geographies face.
NIS2 (EU)
The Network and Information Security Directive 2 requires organisations to maintain records of incidents, risk management measures, and supply chain security assessments producible to competent authorities within tight timelines — an early warning within 24 hours of a significant incident, a full report within 72 hours. Incident documentation must be assembled quickly, accurately, and completely. A secure repository where incident records are stored as they are created — not reconstructed under pressure after the fact — transforms a potential regulatory crisis into a manageable reporting process.
DORA (EU Financial Services)
The Digital Operational Resilience Act imposes detailed requirements on financial entities around ICT risk management documentation, third-party oversight records, and incident classification. Organisations must demonstrate not just that controls exist but that they are actively monitored, reviewed, and updated. A structured evidence repository holding risk assessments, third-party contracts, due diligence records, and incident logs in an organised, audited environment provides the evidentiary foundation DORA demands — without requiring manual assembly under audit pressure.
SOC 2 (US)
SOC 2 Type II audits assess whether an organisation’s security controls have operated effectively over a defined period — typically six to twelve months. The audit is evidence-intensive: auditors require documented proof that controls were in place and functioning continuously, not just at the point of audit. Access logs, incident records, change management documentation, and policy review records must all be produced in a form that demonstrates continuous compliance. A secure, audited repository that maintains these records automatically, with timestamped access logs and immutable storage, significantly reduces the manual effort of SOC 2 evidence collection and strengthens the quality of what is produced.
PCI DSS (Payment Card Industry)
PCI DSS applies to any organisation that stores, processes, or transmits payment card data — which encompasses an enormous range of businesses across every sector. The standard requires extensive documented evidence of security controls: access control records, vulnerability scan results, penetration test reports, incident response records, and audit logs covering a defined retention period. The sensitivity of PCI DSS compliance documentation — particularly vulnerability assessments and penetration test results — makes its storage in inadequately controlled environments a compliance risk in its own right. A breach that exposes a penetration test report is a breach that hands an attacker a map of the organisation’s weaknesses.
HIPAA (US Healthcare)
HIPAA’s Security Rule requires covered entities and business associates to maintain documented policies, risk assessments, workforce training records, and incident response documentation. The evidence requirements extend to demonstrating that access to protected health information is appropriately controlled and audited. HIPAA breach notification requirements create similar timeline pressures to NIS2 — incident records must be complete, accurate, and producible quickly. The administrative and technical safeguard documentation that HIPAA requires is itself sensitive and deserves the protections the rule mandates for health information generally.
ISO 27001
ISO 27001 certification requires documented evidence of the information security management system across its full scope — policies, risk assessments, treatment plans, audit records, management reviews, and incident logs. The certification audit will test not just that these documents exist but that they are controlled, current, and accessible to the right people. Clause 7.5 of the standard explicitly requires that documented information be protected from loss of confidentiality, improper use, and loss of integrity. A secure, access-controlled, audited repository provides the document control framework ISO 27001 requires without a separate document management system.
Cyber Essentials Plus (UK)
Cyber Essentials Plus requires an independent technical audit with documented evidence of controls across five security domains. Organisations seeking or maintaining certification — increasingly required for UK government contracts and supply chain participation — need to maintain organised evidence of their control environment in a form that can be produced quickly for assessment. The evidence itself, which often includes network configuration details and vulnerability information, is sensitive and should be stored accordingly.
What a Secure Compliance Document Repository Looks Like
The solution does not require a dedicated compliance platform with a complex implementation programme. It requires applying to compliance documents the same principles that should already govern any sensitive business information: encryption, controlled access, identity-based authentication, immutable audit trails, and controlled external sharing.
In practice this means a secure, encrypted environment where compliance documents are stored in an organised structure — folders and subfolders by framework, domain, or document type — with access controlled at the document level, every access event logged automatically and immutably, and external sharing managed through authenticated, revocable, audited channels.
Organised structure that reflects the compliance programme
A folder structure organised by framework or compliance domain — incident records, risk assessments, third-party relationships, access control records, regulatory correspondence, governance documents, certifications — provides both a practical working environment and a clear, navigable evidence structure for regulators and auditors. The organisation of the repository itself demonstrates that compliance is being managed deliberately and systematically, not assembled reactively when questions arise.
Encryption that protects sensitive content
Compliance documents — particularly vulnerability assessments, penetration test results, incident records, and regulatory correspondence — are among the most sensitive documents the organisation holds. They should be encrypted at the application level, with access keys controlled by the organisation rather than the storage vendor. A breach of the storage platform produces ciphertext. A legal demand served on the vendor produces nothing useful. The protection is cryptographic, not contractual.
An audit trail that proves integrity
The most important feature of a compliance repository is not what it stores but what it records. Every document stored, every access event, every download, every instance of external sharing — logged automatically, in real time, tied to the verified identity of the person who performed the action, and stored in a form that cannot be altered retrospectively. This audit trail answers the regulator’s integrity question not just with the document but with a complete, immutable record of the document’s history since it entered the repository.
Controlled external sharing with a complete record
When compliance evidence needs to be shared with a regulator, auditor, or external counsel, sharing should happen through a controlled, authenticated channel. The external party is granted access to exactly the documents required, authenticated by verified identity. The organisation retains visibility of what was accessed and when. When the review is complete, access is revoked. The entire sharing event is part of the repository’s audit trail — who was granted access, what they looked at, when it was revoked.
The conversation layer as context
Compliance documents do not exist in isolation. The risk assessment reflects a discussion about priorities. The incident record was shaped by decisions made during the response. The access policy was revised following a governance conversation. A repository that keeps those conversations alongside the documents — in the same secure, encrypted, audited environment — gives regulators and auditors something documents alone cannot provide: the decision-making context that demonstrates the compliance programme is actively managed rather than passively maintained.
The Practical Starting Point
The gap between where most organisations store their compliance documents and where they should store them is not difficult to close. It does not require a dedicated platform, a complex implementation, or significant investment.
The starting point is identifying the compliance documents that carry the most sensitivity and the most regulatory significance — incident records, vulnerability assessments, penetration test reports, regulatory correspondence, third-party risk assessments — and moving them into a secure, encrypted, audited environment with appropriate access controls. The folder structure reflects the compliance programme. The access controls reflect who actually needs to see what. The audit trail builds automatically from the moment the first document is stored.
The compliance team gains an organised, secure, auditable working environment. The organisation gains an evidence repository whose integrity can be demonstrated rather than asserted. And when the regulator calls — or when the incident happens that requires records within 24 hours — the evidence is already assembled, complete, and trustworthy.
Compliance is not just about having the right documents. It is about being able to produce them, prove their integrity, demonstrate who has seen them, and show that the organisation treats its own compliance evidence with the same seriousness it claims to apply to everything else.
The documents that prove you take security seriously deserve to be stored somewhere that proves the same thing.
