What an annual security policy review should produce
An annual policy review should be more than changing the date and collecting a new approval signature. Technology, contracts, staff, vendors, threats, and business processes change during the year. The review is the point at which the organization checks whether the document still describes what it needs to do and what it actually does.
Why annual, and not merely "regularly"
Organizations sometimes treat the yearly cycle as a convention rather than a requirement. It is a requirement, in nearly every framework an organization is likely to be measured against, and the wording converges to a striking degree.
NIST SP 800-53 puts a review obligation in the first control of every family—AC-1, AT-1, AU-1, CA-1, CM-1, IA-1, IR-1 and the rest—each requiring that the policy and procedures be reviewed and updated at an organization-defined frequency, and following organization-defined events. It names neither the frequency nor the events itself, leaving both to be filled in elsewhere. Note that both halves of the pattern are already present in the most general of these frameworks: a schedule, and a trigger that does not wait for it.
That phrase—organization-defined—is misleading, and worth pausing on. It suggests the organization being assessed chooses the value. Usually it does not. The customer, the regulator, or the framework chooses, and the contractor inherits the result. An organization under no external obligation is genuinely free to pick. Every other organization should find out what has already been picked for it.
NIST SP 800-171 carries the requirement forward for organizations handling controlled unclassified information, and supplies the clearest example of that inheritance. In Revision 3 the requirement is 03.15.01: develop, document, and disseminate the policies and procedures needed to satisfy the requirements, then review and update them at an organization-defined frequency.
Fifty of Revision 3's requirements carry such a parameter, and for defense contractors they are not open questions. In April 2025 the department published DoD Organization-Defined Parameters for NIST SP 800-171 Revision 3, defining the values as policy in preparation for making Revision 3 the minimum requirement for contractors.
For the review requirement, the value is explicit. Parameter 03.15.01.b is assigned:
at least every 12 months, or when there are significant incidents or significant changes to risks
The memorandum defines significant in a footnote, as "having or likely to have influence or effect." Both halves of the pattern are there again: a maximum interval, and an event trigger that does not wait for it. Nor is twelve months a one-off choice—it is the value the department assigns to nearly every frequency parameter in the document.
A contractor reading Revision 3 should therefore read that list beside it. The values are a floor rather than a suggestion, and only in four instances did the department leave guidance in place of a specified value.
CMMC rests for now on Revision 2, where the obligation is distributed across the requirement families rather than stated once, and where the interval arrives through a definition rather than a parameter. The CMMC Assessment Guide for Level 2 defines the term the requirements use:
Periodically: Occurring at a regular interval as determined by the OSA that may not exceed one year.
That is the sentence to cite when someone proposes a longer cycle, and it also marks where the organization's discretion begins and ends. Anything shorter than a year is genuinely its own choice; a year is the outer limit of what it may choose. The assessment and scoping guides for every level are published on the DoD CIO's CMMC documentation page.
CIS Controls state it plainly and repeatedly. In version 8.1.2, twenty-one Safeguards close with the same clause:
Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
Only the object varies—documentation, content, the inventory, the policy, the classification scheme. The trigger never does. Most of those Safeguards carry the Govern security function that version 8.1 introduced, which is CIS saying outright that this is governance work rather than paperwork.
Two others, 15.4 and 16.6, require the annual review without the event trigger. That is the exception worth noticing: a schedule with no trigger is the weaker of the two halves, and it is rare. The Controls themselves are free; downloading them requires registration.
PCI DSS is the most explicit of the group. In version 4.0, requirement 12.1.2 sets the interval at least once every twelve months, with updates as needed to reflect changes to business objectives or risks to the environment. Requirement 12.1.1, immediately above it, is the separate obligation to establish, publish, maintain, and disseminate the policy in the first place.
Version 3.2.1 numbered the review requirement 12.1.1, which is worth knowing before quoting a number from memory. A citation carried forward from the older standard now lands on the adjacent requirement.
ISO/IEC 27001 is the outlier, and instructively so. Annex A 5.1 asks that policies be reviewed at planned intervals, and additionally if significant changes occur, without naming an interval. Organizations are free to choose, and the interval they choose is almost always a year, because a longer one is difficult to defend to a certification auditor.
The convergence is the point. Two things recur everywhere: a maximum interval, stated outright by PCI DSS and CMMC and left to the organization by the others, and an event trigger that does not wait for it. A review conducted only when something happens has no floor, and a review conducted only on schedule misses the reorganization in March. Both are required.
An assessor's note on dates
Assessors read review dates as a signal about the organization, not only as a compliance fact.
A policy stating that it is reviewed annually, with a history showing intervals of about eleven months, reads well. It says someone owns the calendar and schedules the work with room to spare.
A history showing 366 days between reviews in a non-leap year reads quite differently. It is one day over, and it will rarely fail an assessment by itself. What it says is that the review happened because the deadline arrived, that nobody noticed it had already passed, and that the organization has no margin anywhere in the process. An assessor who sees that will tend to look more carefully at other practices, because the same habit of just-barely tends not to appear in only one place.
The remedy costs nothing: schedule the review at ten or eleven months and treat the anniversary as the deadline rather than the appointment.
Inputs to the review
The reviewer should consider what has changed since the previous approval. Each category below has a place it ought to be found, and the reviewer needing to ask around for it is itself a finding.
Laws, regulations, and contract clauses
New or changed laws, regulations, grants, customer terms, and standards all bear on whether the policy still says the right thing.
Where to look depends on the obligation. Legal or outside counsel should be tracking statutory and regulatory change for the jurisdictions and sectors the organization operates in. Sector regulators and state attorneys general publish changes directly. Trade associations and sector information sharing organizations frequently summarize them earlier and more usefully than the primary sources. For anything federal, the contracting activity is often the first to say so in writing.
Contract clauses deserve separate treatment, because they are the obligations most often missed. A cybersecurity requirement arriving through a contract or a flow-down is as binding as a regulation and considerably easier to overlook, since it enters through the sales or contracts function rather than through legal or IT. Any clause carrying a security requirement should already be tracked before signature—that is the point at which the organization can still decline it, price it, or negotiate it. The review then works from that register rather than from a fresh reading of every contract.
An organization without such a register has found its first piece of work. It is also, usually, the reason a requirement surfaces for the first time during an assessment.
Changes to systems, data, vendors, and roles
Changes to systems, data, locations, vendors, and organizational roles all potentially invalidate policy language.
These should be discoverable from the change control system rather than from memory. If the organization operates change management with any discipline, the year's changes are already enumerated, dated, and attributed, and the reviewer's job is to read the log rather than to reconstruct the year. Vendor and role changes may sit elsewhere—procurement records, the HR system—but the principle holds: the review consumes records that already exist.
Where the change log cannot answer the question, the gap is worth recording. A policy review is a reasonable place to discover that change control is not capturing what it should.
Incidents and exercises
Incidents and tabletop exercises belong together, because they answer the same question from opposite directions: what actually happens when the plan meets events.
Both should arrive with reports. An incident's final report says what occurred, what the response revealed, and what was recommended afterward. A tabletop exercise report does the same for a scenario that was not real, which is the cheaper way to learn it. Either may show that a policy requirement is unworkable in practice, that a responsibility is assigned to a role that cannot discharge it, or that a procedure everyone believed existed does not.
Recommendations from those reports that were never implemented are especially worth surfacing at review time. A recommendation made after an incident and quietly dropped is a decision the organization made without recording that it was making one.
Audits, assessments, and self-assessments
Audit findings should likewise arrive with a report, and the review should consider both the findings and what became of them.
Beyond external audits are self-assessments, whether conducted internally or by an outside firm. For defense contractors these are not optional exercises. CMMC requires an annual affirmation, submitted by a senior official under 32 CFR 170.22, that the organization has implemented and will continue to maintain the applicable requirements. That affirmation is a legal statement, not an administrative one.
The consequences of getting it wrong are worth stating plainly, because they are frequently underestimated. Misrepresenting compliance status to the government can expose the affirming official to criminal prosecution under 18 U.S.C. 1001, which addresses false statements to federal agencies and carries the possibility of imprisonment. Separately, the organization faces civil liability under the False Claims Act, which the Department of Justice has pursued against cybersecurity misrepresentation specifically since establishing its Civil Cyber-Fraud Initiative in 2021. Because the affirmation recurs every year, so does the exposure.
None of that argues for pessimism in the affirmation. It argues for knowing the answer before signing it, which is what a genuine self-assessment produces and what an optimistic one does not. The policy review is one of the places that knowledge is assembled or found to be missing.
Exceptions and accepted risks
Exceptions and accepted risks are the same subject seen from two angles, and both belong in the review.
A documented exception should already describe what it is an exception to, the risk that accepting it creates, the compensating measures taken, who approved it, and when it expires. Reviewing those is straightforward when the documentation is good: are they still needed, are the compensating measures still in place, and has anything expired without being noticed?
The rest of the organization's risk is a larger question, and it is answered by a risk assessment rather than by the policy review. Many standards require one periodically, CMMC and NIST SP 800-171 among them—which, under the CMMC definition above, means at least annually—and the sequencing matters. A policy review informed by a current risk assessment can ask whether the policy addresses the risks the organization actually has. One conducted without it is reduced to asking whether the document is internally consistent.
Measurements and evidence
Measurements and samples showing whether important requirements were actually met are the difference between reviewing a document and reviewing a practice. This is the same question as whether the policy can be verified at all, asked a year later and with a year of evidence available.
The evidence is often not named in the policy at all, and it usually should not be. The policy states the requirement; the procedure beneath it says what performing that requirement produces, where the artifact lands, and who checks it. So the reviewer's question is not whether the policy identifies its evidence, but whether the policy and its procedures together do.
That question is easy or hard depending on one thing. Where the organization has cross-referenced its documents—each policy statement pointing to the procedures that carry it out, each procedure naming the policy it serves—the reviewer follows the requirement to the procedure to the artifact, and the review moves quickly. Where those links do not exist, the reviewer is reconstructing which procedure implements which requirement before any evidence can be examined, and that reconstruction is the bulk of the work.
Where evidence does exist, the review is also the moment to ask how believable it is. A year of operation is long enough to show what a procedure really produces, and a review that never asks how strong those artifacts are will keep renewing its confidence in the weakest of them.
If no procedure produces evidence for a consequential requirement, that omission is the most useful finding the review will generate.
Overlaps and contradictions
Policies and procedures that overlap or contradict one another need to be reconciled, and the review is where that happens. This is also where confusion between the two documents becomes expensive, since a policy says what and a procedure says how, and a requirement that has migrated into a procedure has escaped the approval authority that was supposed to govern it.
Planned changes
Finally, planned changes that will make current language inaccurate. A policy rewritten to match a system being replaced next quarter has been written twice.
Where to look for these is genuinely organization-specific, and size drives the answer more than anything else. A small organization can find them by asking the handful of people who make such decisions, and that conversation is reliable because there are few enough of them to ask. A larger one needs deliberate sources: the IT and capital project portfolios, the procurement pipeline, budget submissions for the coming year, merger and acquisition activity, facility plans, and whatever governance body approves significant initiatives.
The failure mode differs by size too. Small organizations miss planned changes because nobody wrote them down. Large ones miss them because the person doing the review is not in the room where they were decided.
Speaking with the people who perform the work is essential regardless of size. A document owner may know what the process is supposed to be; operators know where it is unclear, impractical, bypassed, or dependent on undocumented knowledge.
What the report should say
A review that produces no record has not been performed, whatever was discussed. The report is the artifact, and next year's reviewer is one of its readers.
The policy identified precisely. Its title, version, effective date, and scope, along with the reviewer's name and the date the review was conducted. A report that does not identify which version was examined cannot be relied on later, and the review interval cannot be calculated from it.
The evidence and people consulted. What was read, which records were sampled, and who was interviewed. This is what allows someone else to judge how thorough the review was, and what lets a subsequent reviewer avoid repeating work or, more importantly, notice that a source consulted last year was skipped this year.
What is working and remains appropriate. Confirming that most of a policy is correct is a finding, not filler. It records that the language was examined and found accurate rather than merely left alone, and it is the part that makes "no change" defensible.
What should change, and why. Each recommendation with its reason, tied to the input that prompted it: a new contract clause, an incident report, a measurement that came back short. A recommendation without a stated cause is difficult for an approver to weigh and impossible for a successor to understand.
Conflicts, gaps, exceptions, and risks found. Including the uncomfortable ones. A review that surfaces nothing is either describing an unusually mature organization or was not really conducted, and assessors know the ratio between those two.
An owner and a target date for every follow-up action. Not "the IT department" and not "as soon as practical." A named role and a date, because work assigned to everyone is assigned to no one, and this is the part of the report that will be checked next year.
The approval decision and the next scheduled review. Who approved the outcome, on what date, and when the next review falls due—scheduled with margin rather than on the anniversary.
Not every review needs to produce a rewritten policy. "No change" can be a valid result when the report shows what was checked and why the existing language remains accurate.
Conversely, approving edits is not enough when the review uncovers operational work. Those actions need owners and follow-up outside the document workflow, and for anything that cannot be fixed immediately, that means a plan of action and milestones rather than an intention. The distinction matters: an unremediated gap with a documented plan, an owner, and a date is a managed problem, and an unremediated gap without one is simply a gap that has now been written down.
Review related documents together
Policies form a system. An AI policy may depend on privacy, data protection, acceptable-use, procurement, incident response, and records-management rules. Reviewing one in isolation can introduce contradictions or leave a new responsibility without a procedure.
The review is also the natural moment to have procedure owners confirm that their procedures are still accurate—that the steps match what is done, that the named roles still exist, and that the tools referenced are the tools in use. A procedure nobody has read in a year is usually wrong in at least one particular, and the owner is the person who will notice.
That confirmation is worth more when it produces something. Asking each owner to generate a current artifact—the report the procedure says it produces, a dated sample, a fresh export—turns an assertion that the procedure works into evidence that it does, and does it once a year at a predictable time rather than under assessment pressure.
Approval has to mean something
A policy review ends in an approval, and who signs matters as much as that someone did.
The approver must hold enough authority to require compliance from everyone the policy's scope covers. That is the whole function of approval: a policy binds people, and only someone with authority over those people can bind them. A security policy approved by the security manager governs the security team. A security policy that reaches every employee, contractor, and vendor with access needs an executive, an owner, or a board—someone whose authority is not questioned by the department that finds the requirement inconvenient.
This is also where scope and approval have to be checked against each other. A policy whose scope has grown during the review—now covering contractors, or a newly acquired division—may have outgrown the person who approved it last year.
An approver who cannot explain what the organization has committed to has been handed the wrong document, which is usually a sign that the policy has drifted into procedural detail.
The review as a maturity test
The annual review is a useful measure of the organization quite apart from the document it produces. If the organization cannot identify current ownership, evidence, exceptions, and prior corrective work, the problem is larger than stale wording. The report should make that visible rather than hiding it behind a renewed approval date.
The reviews that go quickly are the ones where every input already existed: the contract register, the change log, the incident reports, the risk assessment, the evidence the procedures were supposed to produce. The reviews that take weeks are the ones spent assembling those things for the first time. Which kind an organization has is not really a question about its policies.
Kenneth Ingham Consulting reviews existing policies and procedures and delivers a report of this kind: what is working, what should change, and why and how.