6 Powerful Steps to Document Security Policies and Procedures
Documenting your security policies and procedures is a critical component of the long-term success of any business in the 21st century. This involves far more than doing rote tasks to become compliant with standards such as NIST 800-53 and PCI DSS. Good security is not just a matter of passing audits (you can pass audits and still get breached). Your business must fully support demanding security policies from the highest level, preferably the CEO and the board of directors, and then security must be built-into the corporate strategy so that everyone, both internal and external, is on the same page and actively supporting security and privacy compliance as part of their job responsibilities.
Documenting security policies is much more than just parroting the text from regulatory agencies and compliance documents. You must consider your business needs and circumstances. For example, the requirement for regular patching is obvious, but do you automate the process? Unfortunately, especially on servers, patching can introduce failures in applications and systems. Thus, introduce manual testing steps to ensure patches do not result in unanticipated side effects.
Sometimes writing policies is more a matter of asking “what-if” questions than writing text.
So, what is a good approach to writing security policies to comply with standards such as NIST 800-53 or PCI DSS?
1. Find the Regulatory Documents
The first task is to determine the regulatory and legal standards for compliance. For privacy, these could include GDPR or CCPA (the California Consumer Privacy Act). For security, standards include PCI DSS, NIST 800-53, and ISO 27001. You may also need to follow other standards specific to your industry. Find out which standards apply. A good place to start is to get a list of the audits regularly performed, as well as the regulations and standards used.
Standards are usually interrelated or contain similar, or even duplicate, controls. By compiling a list of all relevant standards, you can write documentation that applies to multiple audits and requirements.
Ensure you are working with the correct version of the standards. Is it version 3, 4, or 5? Is the business interested in complying with the newest standard or is it acceptable to be one version behind?
Ensure you are working with the correct control sets. For example, NIST 800-53 is an enormous set of over 1,200 controls. Businesses often use the so-called “diet NIST” or Cybersecurity Framework instead because these are smaller, more manageable subsets of NIST 800-53.
Go to the website hosting copies of the standards and regulatory documents and download directly from there. This ensures you get the correct versions.
2. Interview Security Leaders
The next step is to interview business leaders and managers to get their viewpoint. You will also need to interview IT leaders, but your primary focus is on the business. Questions include:
- What problems does the business need or want to solve?
- What is driving the business to improve security and privacy?
- Have they failed audits?
- What do they see as weaknesses and strengths?
- Who is currently responsible for security? Privacy?
- What is the goal of the documentation project?
- Is security and privacy supported by the CEO and Board?
- Does the strategic plan of the company include security and privacy?
During this interview process, find out who is responsible for which parts of each policy. You will need to meet with these individuals later, during the next step.
3. Interview Responsible Parties
Third. interview those who implement the policies and associated procedures, including any mitigations.
For third parties, such as SaaS and PaaS vendors, examine their SLAs. attestations and certifications of compliance.
4. Write up Policies and Procedures
Fourth, write up the policies point by point. Document policies and procedures separately. Split the policies up into separate documents for control families and even for individual controls. This way, you can give employees and auditors what they need to see instead of your entire policy set. You may find it beneficial to host your policies and procedures on an intranet using WordPress, Confluence, or a similar product.
Policies should focus on WHO (by title or department) is responsible for WHAT, WHEN, and WHERE, and should be brief and to the point. Always identify the responsible party without ambiguity. Focus on those in the business who enforce the policies. These include:
- individuals (refer to them by title so you do not have to update documentation when people receive promotions, are transferred, or leave the company)
- managers or leaders (again, refer to them by their title)
- department heads
- engineering, IT, security, or other technical groups
Procedures focus on HOW and EVIDENCE.
Recommend scheduling the delivery of evidence regularly: monthly, quarterly, or annually. Businesses should never wait for audits to run around collecting evidence. It is much better and more efficient to always be collecting evidence, so when auditors arrive, they can find all the evidence they need in a series of folders on a shared drive.
5. Gaps in Security Policies
It is quite common during this process to find gaps in your security program. Document these and pass them to the correct people for remediation.
6. Use WordPress or Confluence
Your security and other teams will use this documentation to ensure compliance and by auditors to verify compliance. These policy documents are also good inputs to a ROC or AOC.
Richard is the Owner and Senior Writer for The Writing King, a bestselling author, and ghostwriter. He’s written and published 63 books, ghostwritten 40+ books, as well as hundreds of blog articles.
