Policies, standards and procedures

Security documentation is usually built in layers. A policy states what the organisation intends and why. A standard sets a specific, measurable requirement that supports the policy. A procedure describes the steps people follow to carry it out. Together they turn leadership’s intent into work that can be repeated and checked.

There is no single legal definition of these layers, and organisations use the words differently. What matters is that each layer has a clear job and that the set is consistent. The descriptions below reflect common practice, and your client’s chosen framework may use its own terms.

How the layers differ

NIST’s glossary shows how broad the word “policy” is. One entry, drawn from NISTIR 4734, defines it as a statement of objectives, rules, practices or regulations governing the activities of people within a certain context. Another, from NIST SP 800-175A, describes it as the set of basic principles and associated guidelines, set by an organisation’s governing body to direct and limit its actions toward long-term goals.

In practice, the three layers look like this.

Layer	Answers	Typical owner	Changes
Policy	What do we intend, and why?	Senior leadership approves	Rarely
Standard	What exactly is required?	Security lead	Occasionally
Procedure	How is it done, step by step?	The team doing the work	Often

For example, an access control policy might say that access is granted on a need-to-know basis. A standard might say that administrative accounts require multi-factor authentication. A procedure would describe how a new joiner’s access is requested, approved and recorded.

What frameworks ask for

Frameworks tend to expect all three layers. NIST’s Cybersecurity Framework 2.0 includes a Policy category in its Govern function, which it describes as organisational cybersecurity policy being established, communicated and enforced, with policy reviewed, updated and communicated to reflect changes in requirements, threats and technology.

The Saudi NCA’s Essential Cybersecurity Controls go further in detail. Its policies and procedures subdomain requires that policies and procedures are documented, approved by the authorised official and communicated, that they are implemented, that they are supported by technical security standards such as those for firewalls, databases and operating systems, and that they are reviewed and updated at planned intervals with changes documented and approved. That is a clear picture of the layered approach in one framework.

Why it matters

Documents are what an assessor or an auditor can check. A policy shows that leadership has made a decision. A standard shows what the control is meant to achieve. A procedure and its records show the control is actually carried out. If any layer is missing, the others are hard to evaluate.

For the client, the benefit is more practical: new staff know what to do, and a change in tooling updates a procedure instead of rewriting the policy.

How an MSP or vCISO delivers it

1. Start with what exists. Collect current documents and find which are out of date, duplicated or ignored.
2. Agree the set. Decide which policies the client’s framework and risks require. A short set that is read is better than a long one that is not.
3. Keep each layer in its place. Put intent in the policy, requirements in the standard and steps in the procedure. Avoid product names in policies.
4. Assign owners and approvers. Every document has an owner, an approver and a review date. The risk register shows which risks the documents respond to.
5. Publish and communicate. Staff should be able to find the current version and know they must follow it. Record acknowledgements where the framework asks for them.
6. Review on a schedule. Review at planned intervals and after significant changes, with a version history.
7. Link documents to controls. Show which policy or procedure supports each control, as described in the Statement of Applicability guide.

Our vCISO first 90 days playbook shows where policy work typically fits in an engagement. For framework detail, see the ISO 27001 compliance platform page.

Common mistakes

• Copying a template unchanged. A policy that describes tools or teams the client does not have will not be followed, and it creates a gap between what the document says and what happens.
• Mixing layers. Step-by-step instructions inside a policy make it long and force leadership to re-approve routine changes.
• Writing policies no one approves. An unapproved policy is just a draft.
• Never reviewing them. Documents should change when the business, technology or requirements change.
• No evidence of use. Procedures that produce no records are hard to show to an assessor.
• Too many documents. If staff cannot find the one they need, the set is too big.
• Treating documents as the control. A policy states intent. It does not prove that the control works.

Where GetCybr fits

If you maintain document sets for several clients, GetCybr is a platform for keeping policies, owners, review dates and the links to controls and evidence in one place. It does not write a client’s decisions for them or make a policy effective in practice. You can see how documents fit with the rest of the programme on the frameworks page.

Sources

• NIST Computer Security Resource Center, Glossary: policy. Source for the NISTIR 4734 and NIST SP 800-175A definitions of policy.
• NIST, The NIST Cybersecurity Framework (CSF) 2.0, February 2024. The CSF page links to the full document (NIST CSWP 29), which is the source for the Policy category in the Govern function.
• National Cybersecurity Authority (Saudi Arabia), Essential Cybersecurity Controls (ECC). The linked ECC-2:2024 document is the source for the policies and procedures requirements.