Security Policy and Plan Review Checklist

A small security team reviewing its policies and plans should check 4 things in each one: a named owner, a scope that matches the business today, a current review date, and evidence that people follow it. The 33 items below turn that into a list a reviewer can mark done, in 9 sections mapped to the 6 NIST CSF 2.0 functions.

The same checklist is available as a PDF, with no form to fill in. Download the checklist as a PDF.

How to use this checklist

• Run it with 2 people: the owner of the policy set and a reviewer who did not write the policies.
• Mark each item done, not done or not applicable, and give every item that is not done an owner and a date.
• Run it at every scheduled review and after any major change, such as an acquisition, a new core system or a serious incident.
• Keep each completed checklist with its date, because it is the evidence that the review happened.

How the sections map to NIST CSF 2.0

The NIST Cybersecurity Framework 2.0, published in February 2024, is organized around 6 functions: Govern, Identify, Protect, Detect, Respond and Recover. Each section below names the functions it serves, so a team that reports against CSF 2.0 can file the results under its own headings.

The checklist

1. Governance and ownership (Govern)

1. Every policy and plan names one accountable owner, by role and by name.
2. Senior leadership has approved the information security policy, and the approval is dated and recorded.
3. The roles that run security are written down, including who may accept a risk on the business's behalf.
4. An index lists every policy, standard and plan with its owner, version and next review date.

2. Scope and currency (Govern, Identify)

5. Each policy states the business units, locations, systems and data it covers, and that scope matches the business as it runs today.
6. Systems, cloud services and suppliers added since the last review are covered by the policies that apply to them.
7. Every reference to a standard or regulation names its current version, such as ISO/IEC 27001:2022 or NIST CSF 2.0.
8. The laws, regulations and contract terms that apply to the business are listed, and each one points to the policy that meets it.

3. Access (Protect)

9. The access policy requires multifactor authentication for remote access, email and every administrator account.
10. The policy lists the second factors that are allowed, and it treats one-time codes sent by SMS as a restricted authenticator, the status NIST SP 800-63B gives them.
11. Privileged access is granted only with a named approver, and privileged accounts are reviewed on a stated schedule.
12. Access is removed within a stated time when someone leaves or changes role, and recent leaver records show that it happened.

4. Data (Identify, Protect)

13. A data classification scheme exists, and each class says how that data is stored, shared and deleted.
14. The policy states where encryption is required at rest and in transit, and who holds and manages the keys.
15. Each class of data has a retention period, and deletion at the end of that period is recorded.

5. Incident response (Detect, Respond)

16. The incident response plan names the incident lead and a deputy, and says how to reach both outside working hours.
17. The plan defines severity levels and says who decides when an incident goes to senior leadership.
18. The plan lists every notification duty the business has, with its recipient and its deadline. For a US public company, the list includes disclosure of a material cybersecurity incident on SEC Form 8-K Item 1.05 within 4 business days of the materiality determination.
19. The logs the plan relies on are named, switched on and kept long enough to investigate an incident.
20. The plan has been exercised in the last 12 months, and what the exercise taught has been written into the plan.

6. Business continuity and recovery (Recover)

21. Each important service has a recovery time objective and a recovery point objective, set from a business impact analysis.
22. The continuity plan lists the people, systems, sites and suppliers that each important service depends on.
23. Backups are defined for each important system, including how often they run and where the copies are kept.
24. A restore or failover test has shown that each important service can be recovered within its recovery time objective, and the result is dated.

How to set those objectives and test them is explained in how quickly a business should recover from a major IT outage.

7. Third parties (Govern, Identify)

25. A register lists every supplier that holds company data or connects to company systems, with an owner for each.
26. Suppliers are tiered by the data they hold and the access they have, and each tier has a review frequency.
27. Contracts with high-tier suppliers cover security requirements, breach notification, audit rights and the return of data at exit.
28. The date of each high-tier supplier's latest security evidence is recorded, and evidence more than 12 months old has been requested again.

Item 28 matters because a supplier's answers describe its controls on paper. In the DigitalXForce Security Posture Benchmark 2026, 54.9% of 2,112 companies report at least one Data Protection and Encryption control not in place. The 30 minute cloud vendor review shows how to check a supplier's answers.

8. AI use (Govern)

29. An acceptable use policy for AI tools says which tools staff may use and which data may never be entered into them.
30. An inventory lists the AI tools and AI features in use, including AI built into existing software, with an owner for each.
31. The AI policy names the framework it follows, such as the NIST AI Risk Management Framework 1.0 or ISO/IEC 42001:2023, and records whether the EU AI Act, Regulation (EU) 2024/1689, applies to the business.

9. Evidence and review cycle (Govern, Identify)

32. Each policy has at least one piece of evidence that it is followed, such as an access review record or a restore test report, and staff acknowledgements of the current version are kept.
33. Exceptions to any policy are recorded with an owner, a reason and an expiry date, and expired exceptions have been closed or renewed.

What to do with the results

Every item marked not done becomes a task with an owner and a date. Carry the open tasks into the next review, so each completed checklist also shows what changed since the last one.

Where software helps, and where it does not

A team with a small policy set can run this checklist in a shared document with a calendar reminder, and DigitalXForce is not needed for that. Software earns its place when policies have to be checked against several frameworks and tied to the controls that enforce them. DigitalXForce's AI-Powered Policy and Compliance Management module reviews and generates policies, standards and plans, benchmarks them against NIST and industry regulation, and publishes the results to the controls they govern. The glossary entry gives the short definition.

For the controls a small business should have in place before the paperwork, read affordable cybersecurity for small and midsize businesses.

Questions about reviewing security policies

How often should security policies be reviewed?

DigitalXForce recommends a scheduled review of every policy and plan at least once a year, and an early review after any major change. Record the next review date in the policy itself. A regulated business should also check the review frequency its regulator or certification body expects.

What is the difference between a policy, a standard and a plan?

A policy states what the business requires and who is accountable for it. A standard sets the specific rules that meet the policy, such as which second factors are allowed. A plan sets out what people do in a defined situation, such as an incident or an outage.

Does a small business need a written incident response plan?

A small business needs one as much as a large one, because an incident is the worst time to decide who does what. The plan can be short. It should name the lead, the escalation route, every notification deadline and how to reach each person outside working hours.

How does this checklist map to NIST CSF 2.0?

Each section names the NIST CSF 2.0 functions it serves. Governance, scope, third parties, AI use and the review cycle sit under Govern, and scope, data, third parties and the review cycle also serve Identify. Access and data sit under Protect, incident response under Detect and Respond, and continuity under Recover.

Can this checklist replace an audit?

The checklist shows whether policies are owned, current and followed. It does not replace an independent audit, such as an ISO/IEC 27001:2022 certification audit or a SOC 2 examination against the AICPA Trust Services Criteria. Keep each dated checklist as evidence that reviews happen.

Do this once instead of every audit

Every item above can be checked by hand. DigitalXForce automates the review of policies and plans against NIST and industry regulation and ties each one to the controls it governs. It maps the result to 50+ frameworks once and keeps the evidence current between audits. A 30 minute walkthrough on your own framework set shows what that removes from your calendar.

Request a demo