A well-documented security program protects your business. The distinction matters because companies that treat compliance as a checklist exercise get breached at the same rate as companies that ignore compliance entirely. The documentation has to reflect how your organization works, and no regulatory template can tell you that.
I care about this more than people expect. A policy binder nobody follows gives a company a false sense of safety, and I’d almost prefer a company had nothing, because at least then it would know it was exposed. The people who pay for that false sense are the customers whose data sat behind a policy nobody read. This is the first in a series about how to document security policies and procedures. The second article, “Security Policy Regulatory Documents,” covers how to identify, organize, and interpret the regulatory standards that apply to your business.
Who should own security policies in a company?
The policy needs to document what you do, not what the standard generically recommends.Share on X
Policy without a named owner at the executive level turns into a document nobody defends when the budget gets cut. I’d want one senior person whose job depends on those policies being real, and a board that asks that person hard questions every quarter.
What does going beyond compliance mean for security policies?
Documenting security policies means more than copying text from regulatory standards like NIST 800-53 or PCI DSS. It requires thinking through how each requirement applies to your specific business. Take patching as an example. Every standard requires regular patching. But do you automate the patching process, knowing that automated patches can introduce application or system failures?
Or do you add manual testing steps to catch problems before they hit production? The policy needs to document what you do, not what the standard generically recommends. Every business has unique infrastructure, risk profiles, and operational constraints. Cookie-cutter policies that parrot regulatory language without addressing these specifics fail both in audits and in practice. Good documentation reflects decisions your organization has made about how to implement each control, including the tradeoffs involved.
I have no respect for consultants who sell cookie-cutter policy packs. They hand a company a stack of borrowed language, collect their fee, and leave the staff to find out later that half the procedures describe systems the company doesn’t run.
Equifax had a patching policy on paper. In March 2017 the company learned of a critical flaw in Apache Struts, open-source web software it ran, and its security team emailed more than 400 people telling them to apply the patch within 48 hours. According to the FTC, nobody followed up to make sure it happened. The vulnerable system stayed unpatched, and on May 13, 2017, attackers got in and stayed for 76 days.
It got worse. A December 2018 House Oversight Committee staff report found that a device meant to monitor that traffic had been blind for 19 months because of an expired security certificate, and the committee called the breach “entirely preventable.” The attack exposed personal information on about 147 million people, and in July 2019 Equifax agreed to pay at least $575 million, and up to $700 million, in a settlement with the FTC, the CFPB and the states.
That’s the gap I keep talking about. The policy said 48 hours, and no one had the job of proving the patch went on. I think Equifax is the clearest case I know of a written policy doing nothing because nobody had to show it was followed, and it betrays every one of those 147 million people.
How Do You Document Security Policies?
Find the regulatory documents. Identify which standards apply to your business: GDPR, CCPA, PCI DSS, NIST 800-53, ISO 27001, HIPAA, SOX, or others depending on your industry and geography. Compile a complete list and make sure you have the correct version of each standard. Companies frequently reference outdated versions. That creates compliance gaps that appear during audits. Interview security leaders. Talk to business leaders, managers, and IT leadership about the organization’s security posture. Understand the driving factors: previous audit failures, known weaknesses, strengths, and the level of executive support for security initiatives. These conversations shape the direction of the entire documentation project. Interview the people who implement the controls. The people responsible for executing policies and procedures often know things that leadership doesn’t. Include third-party vendors and service providers. Review their Service Level Agreements, attestations, and compliance certifications. Your security posture is only as strong as your weakest vendor. I’d push hardest on this step. The people doing the work will tell you which written procedures they ignore and why, and that conversation is worth more than anything leadership says in a conference room. Write policies and procedures separately. For a real case, see a NIST 800-53 compliance project. For more on the hidden risks of trade compliance, see Richard’s interview with César Dongo. Policies define who, what, when, and where. Procedures define how. Keeping them separate makes both more useful. Consider splitting policies into separate documents for each control family so that employees and auditors can find specific information without reading through irrelevant material. Hosting these on an intranet using platforms like WordPress or Confluence makes them accessible and manageable. Identify gaps. Every documentation project uncovers gaps in the security program. This is normal and valuable. Document the gaps, assign them to the suitable teams for remediation, and track them to closure. The gaps you find during documentation are gaps that would otherwise appear during an audit or, worse, during a breach.
How should employees be trained on security policies?
Policies that employees don’t know about don’t protect anything. Training has to be regular, practical, and specific to each role. Generic annual security awareness training satisfies an audit requirement but doesn’t change behavior. Effective training explains why the policies exist, what the real risks are, and what each person’s specific responsibilities include.
The goal is a workforce that makes security-conscious decisions by default. Security teams that call employees the weakest link and then train them with a once-a-year slideshow deserve the results they get.
How often should security policies be reviewed?
Security policies are living documents. This is what my cybersecurity ghostwriting handles for you. Threats change, new vulnerabilities emerge, regulations get updated, and your business evolves. Policies that were adequate last year may have gaps today. Conduct periodic risk assessments, review policies against current standards, and update documentation when your infrastructure, processes, or regulatory environment changes. An annual review cycle is the minimum. Significant changes to your business should trigger an immediate review.
What Belongs in an Incident Response Plan?
Prevention-focused policies are necessary but insufficient. You need documented incident response and recovery procedures that outline what happens when something goes wrong.
Clear roles, communication channels, escalation procedures, and recovery steps, all documented before the incident occurs. Test these procedures regularly. An incident response plan that’s never been tested is a plan that will fail when you need it most.
Why is security documentation more than a compliance exercise?
Security documentation is the foundation of how your organization protects sensitive data, manages risk, and responds to threats. Treat it as a strategic asset, keep it current, and make sure the people who need to follow it know what it says. A company that writes policies only to get past an auditor is gambling with its customers’ data, and I don’t think anyone who’s lived through a real outage would make that bet twice.
