Last Updated July 24^th, 2023

How can I ensure my organization drives towards a secure technology environment where my users understand their responsibilities and follow the rules to secure my assets and data? How do I demonstrate a sound technology and security program to auditors, assessors, and regulators? The first step to accomplishing all these things is a good policy stack.

Policy documents (policies, standards, and procedures collectively) are a vital aspect of any organization’s technology and security programs. These documents are where your staff goes to understand their roles and responsibilities, what’s expected of them regarding the confidentiality, integrity, and availability of your organizational data and assets, and what to do when something goes wrong.

When writing policy documents, there are many things to consider. First, let’s look at the difference between the three levels of documents.

• Policy – A high-level document setting the general expectations for what programs need to be in place. These documents should not change often and lay out the parameters or boundaries for each area.
• Standard – These documents sit beneath policies and are intended to codify what the organization will do to meet the requirements set forth in the parent policy. This is where most of your chosen requirements (more below) will go.
• Procedure – These documents clearly define how the requirements of the parent standard(s) are implemented. They contain step-by-step, detailed information on the controls being implemented.

Where do I begin?

When defining or updating a policy stack, the first decision that should be made is on what you want your documents to be based. Regulatory requirements are often necessary, but perhaps you want to layer on a framework, such as NIST or ISO 27001. Such frameworks memorialize the controls selected by your organization. They should be selected based on a risk assessment conducted to understand the current state and allow senior leadership to determine the desired state. This defines a clear set of requirements on which your policy documents are to be based and allows for assessment against those requirements to determine your organization’s level of compliance and define the initiatives necessary to close the gaps in coverage.

Next, define a hierarchy. This can be mapped to the areas of your organization’s technology structure (such as Cybersecurity, IT Asset Management (ITAM), Operations, etc.), which will also establish ownership and accountability for creating and maintaining your policy documents.

Writing the Policies

Now that you’ve decided what to write, by whom they will be written, and the organizational structure, it’s time to start writing. When writing policy statements, you should consider a few key aspects of policy content.

• Use objective language, such as the word must instead of words like “will,” “shall,” or “should.”
• Keep statements as clear and concise as possible. The less open to interpretation, the better.
• Keep statements focused on what must be done. There should be a separate Roles and Responsibilities section that assigns accountability and responsibility to these actions. This lowers the likelihood of missing a title or team name when modifying documents because of organizational changes or changes in responsibilities. All statements must have a corresponding item in the Roles and Responsibilities section to establish Accountability and Responsibility for every policy statement.
• Define technical terms. Policy documents should be written to cater to a non-technical audience (such as a regulator, an external assessor, or an internal auditor). Therefore, technical terms should be defined in a glossary (recommended) or within a Definitions section of the document. A separate, centralized glossary reduces the risk of conflicting definitions across multiple documents and ensures a single definition for a given term is used across multiple contexts.
• Focus on the 90%. There may be some use cases that require exceptions to policy documents. Policy documents should be tailored to most cases, with the remaining 10% going through a formalized exception process.

Document Review, Publication, and Maintenance

Once created, the documents need to be reviewed. This should be a collaborative effort between the author(s), Subject-Matter Experts (SMEs), and key stakeholders, as defined in the Roles and Responsibilities section as having either responsibility or accountability for implementing the requirements defined in the policy document.

Having a formalized committee can help resolve disputes and be the point of escalation for disagreements, but for smaller organizations, this may be done by the party(ies) accountable for the policy’s implementation (be it the governance, objectives, or controls). Sometimes there will be a difference in opinions between key stakeholders across functional areas, requiring a single point of authority to weigh in and determine the best way to proceed. Formal documentation of the review process, including comments made, responses to them, and signoff by the final approver(s) should be retained for evidence purposes.

Best practice dictates that policies and standards be reviewed at least annually. They should also be reviewed when significant changes occur within the organization (introducing new products or hardware, major upgrades to existing infrastructure or software, or mergers and acquisitions) or a major shift in the threat landscape impacting the organization’s critical business functions and sectors.

Now that we’ve covered the basics of creating quality policy documents, reach out to us so we can help get your organization’s policy stack created or updated to align with these practices.