Short answer: Review a security policy by checking whether its scope, roles, requirements, controls, evidence, exceptions, and review triggers still match current practice. Keep accurate sections, correct only what changed, and record the review decision.
Start with the inventory
Confirm that the policy is the approved version and record its owner, status, effective date, and related processes or controls. Check for duplicate or superseded copies before editing.
Test the policy against reality
Ask the people who perform the work whether the systems, roles, suppliers, data, and steps described are still true. Mark future work, assumptions, and unknowns. A policy can require an activity, but it cannot prove that the activity happened.
Check the decisions that matter
Review scope, accountable owner, approval path, exception handling, evidence expectations, and the trigger for the next review. Remove obsolete requirements and split changing tool instructions into a procedure or standard.
Record a proportionate outcome
The result may be confirm, revise, retire, or defer with an owner and date. Record reviewer, date, changes, open gaps, and approval. Do not rewrite accurate language merely to make the document sound newer.
Practical example
A review of the supplier policy starts with its approved version and owner, then checks whether a new data processor, approval workflow, and retention requirement are covered. Unchanged sections stay intact; the changed requirement gets an owner, decision, and new review date.
FAQ
What should a policy review check?
Check scope, ownership, requirements, controls, evidence, exceptions, links, and review triggers against current work.
When should a policy be rewritten instead of edited?
Rewrite when scope, purpose, structure, or the operating model has materially changed. Otherwise, a controlled targeted update is easier to review.