A.5.1 Policies for information security: requirements and evidence

What A.5.1 policies for information security requires in practice

When an auditor asks for the policy set, they want two things: an approved information security policy and a set of topic-specific policies beneath it that the organization has communicated, had acknowledged by relevant people and interested parties, and reviewed at planned intervals and after significant changes. Control A.5.1 in ISO/IEC 27001:2022 Annex A asks for exactly that. The risk it addresses is simple: if rules exist on paper but are inconsistent, out of date or unknown to the people expected to follow them, the controls that depend on them have no stated basis and cannot be tested. The difficulty is that policies drift from practice over time, and ownership is often unclear. A policy written by one team may be approved by no one, cite tools that have since been replaced, or be stored in a folder nobody checks.

Keep A.5.1 separate from two neighbors. Clause 5.2 of the standard is the top-level information security policy that top management sets, and it sits in the management system requirements rather than Annex A. A.5.1 covers that policy together with the topic-specific policies beneath it. In the 2013 edition, the same ground was split across A.5.1.1 (policies for information security) and A.5.1.2 (review of the policies), and the 2022 edition merges them into one control. Your mapping from the old controls should therefore point both 2013 identifiers at A.5.1, and your evidence should show approval, communication, acknowledgement and review for each document.

Start by confirming who approves each policy, which document owner maintains it, and what review interval and triggers you have set for each. Then check that every policy has an approval record, a version history and a list of who acknowledged it, and that the acknowledgement covers the relevant staff and any external parties your scope names. An auditor will usually sample a few topic-specific policies and ask to see this trail for each. Ask your team, or any outside help, to show that trail for three or four policies before the audit, because gaps are much cheaper to fix in advance than during fieldwork.

Which policies and parties fall inside A.5.1 scope

A.5.1 is satisfied only when the right policies exist, the right people and parties have them, and the policies bind every part of the organization that the ISMS covers. The cards below separate the policy set, the audience, and the scoping choices that change how much work the control creates.

The top-level information security policy

The information security policy is the overarching document that sets direction for the whole ISMS. Clause 5.2 requires top management to set it, while A.5.1 requires it to be approved, published and communicated. Check that it names its owner, states its purpose and scope, and points to the topic-specific policies beneath it. An auditor will ask who approved the current version and when it was last reviewed.

Access control and identity policy

An access control policy sets the rules that the identity, authentication and access rights controls implement. Without it, the access reviews and joiner, mover and leaver steps have no agreed standard to measure against. Confirm that the policy covers privileged accounts, shared and non-human identities, and how approvals are recorded. Pair it with the evidence that access reviews actually happen.

Acceptable use and asset handling policy

Acceptable use rules tell personnel what they may do with organizational information and devices, and how each classification level must be handled. Auditors look for evidence that the policy reached staff, contractors and anyone holding company equipment or data. Check that it covers personal devices, removable media and return of assets at the end of an engagement.

Supplier and cloud policy

A supplier policy sets how information security risks from third parties are assessed before contracts are signed and monitored afterward. It also governs cloud service use, including the split of responsibilities with each provider. Confirm that the policy applies to outsourced services that process organizational data, not only to suppliers that appear on the procurement list. Ask which teams may buy cloud services without security review.

Incident and continuity policy

Incident management and ICT continuity rules need their own topic-specific policy so that reporting duties, escalation and recovery expectations are fixed in advance. The policy should name the events that count as incidents, the reporting route for staff, and who may declare a disruption. Confirm that it matches the procedures used during real exercises, since a policy that differs from practice creates a nonconformity.

Business units, subsidiaries and sites

The scope statement determines which entities the policies bind. A policy written for headquarters may leave a subsidiary, a remote office or a data center outside its reach, and the gap appears at audit. Decide early whether each legal entity, site and outsourced operation follows the group policy directly, through a local adoption, or under a contractual commitment. Record that decision in the scope document.

How an assessor tests the policy set

This table sets out the steps an auditor follows to test A.5.1, what each step checks, and the findings that most often come up. Read each row as a test: the evidence on the left is what the assessor asks for, and the right column shows where organizations usually fall short.

Test step	What the assessor checks	Common finding
Confirm the policy set exists	The information security policy and each topic-specific policy are present, named and scoped to the organization's ISMS	Topic policies referenced in procedures or the Statement of Applicability but never written
Confirm management approval	Each policy shows approval by an authorized manager, with the approver's name, role and approval date	Drafts circulated as final, or approvals given by a manager with no authority over the policy
Check publication and version control	The current version is easy to find, carries a version number and change history, and superseded versions are withdrawn	Several live copies on shared drives with conflicting content
Sample acknowledgement records	A sample of employees, contractors and other relevant parties shows acknowledgement of the current policy version	Missing acknowledgements for contractors, temporary staff or staff who joined after the last issue
Compare review dates to the planned interval	Each policy has a set review interval, and the last review date falls within it	Reviews skipped, or review dates recorded without a documented review outcome
Check reviews after significant change	Policies were reviewed after events such as a new cloud platform, a merger, a major incident or a regulatory change	No record of a review after a change that clearly affected the policy
Verify policies match practice	Staff interviews and system settings reflect what the policies require, such as access rules or acceptable use	Policy requires controls that operating teams do not run or cannot show
Trace findings to corrective action	Nonconformities are logged, owned and closed with evidence that the policy was updated or practice changed	Findings closed by editing the document without changing how work is done

How to build and maintain the policy set step by step

This sequence turns the risk assessment into a policy register that management has approved, staff have acknowledged and someone reviews on a fixed cycle. Each step produces a record an auditor can sample, so the policy set stays current and provable.

Inventory the required topic policies
Start from the risk assessment and the statement of applicability to list every topic policy the organization needs, such as access control, acceptable use, supplier security, incident management and cryptography. Also record the legal, contractual and regulatory obligations that the policy set has to address, since A.5.31 feeds directly into this list. Each entry should name the risk or requirement that justifies it. The output is a draft policy register with one row per policy, its scope and its driver, which the policy owners review before drafting begins.
Draft policies and assign named owners
Write each topic policy in plain language, scoped to the systems, people and sites it covers, and assign a named owner who is accountable for its content and upkeep. Owners should be people with authority over the subject, which links this step to the role definitions in A.5.2. Keep the top-level policy under clause 5.2 consistent with these documents. The output is a set of draft policies, each with a version number, an owner and a stated scope, recorded in the register.
Obtain management approval
Submit the draft policy set to top management or the body it has delegated approval to, and record the decision for each document. Approval should be dated and tied to a specific version, so that a later edit cannot pass as the approved text. Reviewers should confirm that policies match the risk appetite and resources the organization has set. The output is an approval record per policy, such as minutes or a signed register entry, showing who approved which version and when.
Publish to a controlled repository
Move the approved policies into one controlled repository that staff can reach and that keeps version history, so readers always see the current approved version and older versions stay retrievable. Restrict edit rights to policy owners and make the repository's access model match the roles in the organization. Platforms such as XWiki keep version history with who changed what and when, and BookStack assigns permissions through roles. Confirm with your chosen tool how it handles approval status and audit trails. The output is a live policy location with a visible version and approval status on each document.
Communicate and collect acknowledgements
Notify the relevant personnel and, where appropriate, interested parties that the policies are published and where to find them, then ask each person to acknowledge that they have read and understood the policies that apply to their role. Track who has acknowledged, who has not, and what follow-up was taken for the gaps. Acknowledgements should be tied to the version the person read, so a later revision triggers a new acknowledgement. The output is an acknowledgement log that can be exported and sampled against the personnel list.
Set the review cycle and triggers
Set a planned review interval for each policy and record the trigger conditions that force an earlier review, such as a material incident, a new regulation, a major system change or a change in the business. Assign each review to the policy owner and a reviewer for the approval step. The interval should be stated in the policy register so an auditor can see the plan and check it against the review records. The output is a review calendar and a trigger list attached to the register, with the next review date for every policy.
Rerun the cycle after significant changes
When a review is due or a trigger occurs, update the policy, record the change, obtain approval again, publish the new version, and collect fresh acknowledgements from the affected people. Retire superseded versions in a way that keeps them available for evidence. Feed findings from compliance reviews and internal audits into the next revision, which connects to A.5.36 and the improvement process. The output is a closed change record for each revision, showing the cause, the approver, the publication date and the acknowledgement count, which together show that the policy set is maintained in practice.

Who approves policies, and how they reach people

Under A.5.1, the approver and the drafter are different roles, and an auditor will want to see both named. Policy owners, such as the security team, IT or HR, draft the information security policy and topic-specific policies. Management approves them, and the approver must be someone who can accept the residual risk the policy leaves on the business and who has the authority to fund the controls it requires. A drafter who also signs off is a common finding, because nobody senior has accepted the risk. Confirm your own approval chain: which executive or board committee approves the top-level policy, which manager approves each topic-specific policy, and whether that approval is recorded with a date and version number.

Communication differs by audience. Employees usually receive policies through the intranet or wiki, a training module and onboarding, with acknowledgement captured in the HR system or a learning platform. Contractors need the same policies through their contract or statement of work, since they are often outside the employee onboarding path. Relevant third parties, such as key suppliers, receive only the parts that affect them, usually through the supplier agreement or a security schedule, and the distribution list should say who got what. Decide which audiences receive which documents before publishing, because a policy that never reached a contractor is hard to defend in an audit.

Auditors look for proof that the right people received the right version and acknowledged it. Expect to show the approved document with its version history, a distribution record, and an acknowledgement log that links each named person to the policy version they accepted, with dates. Sample checks often compare the current headcount and contractor list against the acknowledgement records, so gaps are visible quickly. Reacknowledgement after a material change, and a plan for people who have not acknowledged, are both things to define in advance. Ask your auditor which sample and format they will accept before you build the evidence.

Evidence that passes an A.5.1 audit

An auditor testing A.5.1 wants to see that the policy set exists, was approved by management, reached the people it governs, and is reviewed on a schedule. The cards below cover the artifacts that prove each of those points, and how to keep each one current between audits so it does not drift from practice.

Signed top-level information security policy

This is the approved information security policy that sits under the clause 5.2 requirement and anchors the topic-specific set. Auditors check that a named member of top management approved it, that the approval date is recorded, and that the version in circulation matches the approved one. Keep it current by tying each review to a calendar entry and recording the approver's sign-off on the document itself. Confirm the approval date appears on the signed version, not only in a change log.

Topic-policy register with owners

A register lists every topic-specific policy, its owner, its approval date, its next review date and its current version. Auditors use it to confirm that the policy set is complete and that no policy has passed its review date without action. Update the register whenever a policy is created, retired or merged, since a register that lags behind the document store is one of the most common findings. Include a link to each policy so the auditor can open it directly.

Version history showing approvals

Version history shows what changed in each policy, when, and who approved the change. Auditors compare the current text with earlier versions to judge whether reviews were substantive or only re-dated the document. Wiki and document platforms that keep page revisions with author and timestamp give this record without extra effort, but the approval step must still be captured, for example with a required approval field or a linked ticket. Confirm that revisions cannot be deleted by editors who also approve them.

Policy acknowledgement records

A.5.1 expects relevant personnel and interested parties to receive the policies and acknowledge them. Auditors sample people from the staff list and ask for their acknowledgement of the current version, so a record that shows an older version was accepted will not pass. Keep the record linked to the staff directory so that joiners are added at onboarding and leavers are removed from the population. Re-issue policies for acknowledgement after each approved change, and keep the timestamps.

Management review minutes

Minutes from the reviews that management holds on the policy set show that the policies were examined at planned intervals and after significant changes, and that decisions were recorded. Auditors look for the attendees, the policies reviewed, the findings and the actions assigned with owners and due dates. Keep these minutes in the same repository as the policies, and schedule the review meeting in advance so that the planned interval can be shown to have been met.

Change log for significant changes

A change log records the events that triggered an out-of-cycle policy review, such as a new cloud platform, an acquisition, a material incident or a change in regulatory obligations. Auditors use it to test the second half of the A.5.1 review requirement, which applies after significant changes as well as on a schedule. Keep entries short and dated, and link each one to the review that followed. An empty log is only credible if the organization can show the change monitoring that would have produced an entry.

What meeting A.5.1 costs in money and effort

This table breaks down the cost and effort components of keeping an A.5.1 policy set current and auditable, marking each as one-time or recurring and naming what drives it up. Read it as a checklist for scoping a quote: the largest recurring costs are people's time for review and acknowledgement, and the license line is the one open-source tooling can usually remove.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Policy authoring	Internal security lead, or an outside consultant or implementation partner if scoped in writing	One-time at first build, then recurring when policies change	Number of topic-specific policies, how many already exist, and how much is copied from templates
Management review and approval	Top management and policy owners who approve each policy	Recurring at each planned review and after significant change	Number of approvers, meeting cadence, and how many policies need a decision each cycle
Repository or wiki tooling	Licenses or hosting for the document system, plus administrator time	Recurring for licenses or hosting; setup is one-time	Per-user licensing versus self-hosted deployment, and the number of users who must read policies
Communication and acknowledgement tracking	Security team to publish, chase and record staff and relevant third-party acknowledgements	Recurring at each policy change and for new joiners	Headcount, contractor and supplier population, and whether acknowledgements are captured in a system or by email
Annual or event-driven review	Policy owners, security lead and reviewers checking content against current practice	Recurring	Rate of change in technology, regulation and contracts, plus the number of policies with review dates
Evidence preparation for auditor sampling	Security lead to assemble approvals, version history and acknowledgement records for the auditor	Recurring at each audit cycle	Quality of version history, whether approval records are kept in one place, and the number of sites or business units in scope
Auditor sampling time	Certification body auditors, whose fees are set by the certification body	Recurring at each surveillance and recertification audit	Scope size, number of sites, and how many policy samples the auditor selects
Software license spend	Vendor for commercial document or policy management products	Recurring	Seat count and contract terms; self-hosted open-source tools can remove this line but still need hosting and administration
Quote request checklist	Ask each provider to itemize authoring, review cycles, tooling, acknowledgement tracking and audit support separately	Applies at procurement	Confirm which items are fixed scope and which are retainers, and whether hosting and licenses are included

Which open-source wikis keep policy evidence

XWiki keeps every change to a page under version control, which matters for A.5.1 because an assessor will ask who changed a policy, when, and what the previous approved text said. The page history records what changed, when and by whom, so the policy owner can show the sequence of revisions behind each review cycle.

Change record: each revision captures what changed, when and by whom, giving the auditor a trail that links edits to the review dates set in the policy.
Version comparison: any two versions can be compared, which helps the policy owner show exactly what changed between the approved edition and a later draft.
Rollback: an earlier version can be restored after a faulty edit, but the restoration is itself a change, so record the approval that justified it.
Approval is separate: version history shows who edited a page, not who authorized the edit, so confirm whether an approval step or extension is needed to meet the approval requirement.

Before relying on XWiki history as audit evidence, confirm with the XWiki blog on document version control and your installed release how history is retained, how deletions are recorded and who can alter the history.

Where A.5.1 policy programs usually fail

Most A.5.1 findings are not about missing documents. They come from policies that were never approved, drifted away from daily practice, or stopped having an accountable owner. The cards below cover the failure points an assessor is most likely to sample, and how to close each one before the audit.

Drafts that were never approved

A policy that sits in a shared drive marked version 0.4 does not meet A.5.1, which expects management to approve the information security policy and topic-specific policies. Assessors ask for the approval record, the approver's name and the date. Check that every policy in the set carries an approval record that matches its current version, and that the approval was given by someone with the authority to bind the organization. Retire superseded drafts so they cannot be mistaken for current text.

Policies that do not match practice

A password policy that requires rotation every 90 days while the identity system enforces no rotation is a policy the auditor can disprove in one sample. For each topic-specific policy, list the operational control that implements it and the system setting or record that proves it. Where the two disagree, either change the policy or change the system, and record which one was done and why.

Missing acknowledgements from contractors

Employees often sign policy acknowledgements at onboarding, while contractors, temporary staff and outsourced operators are never asked. A.5.1 expects relevant personnel and interested parties to be told about the policies and to acknowledge them. Build acknowledgement into the contractor onboarding step and the access request, so that no account is granted until the acknowledgement is on file. Run a periodic report that lists active non-employee identities without a current acknowledgement.

Review dates ignored after reorganizations

A review cycle written into the policy header means little if a merger, a new cloud provider or a team restructure happens between reviews. A.5.1 requires review at planned intervals and after significant changes. Keep a register of each policy with its owner, review interval and next review date, and add a trigger step to the change process for reorganizations, new hosting models and material supplier changes. Confirm the interval you set in your own documents, since the standard does not fix one.

Policies without named owners

When a policy has no owner, nobody notices that it has gone stale, and nobody can answer an auditor's question about it. Assign each information security policy and each topic-specific policy to a named role, not a team alias, and record the owner in the register and in the document itself. Owners should be able to explain how the policy is applied and should be the first to review changes to it. Check that the owner list matches the current organization chart.

Policies stored without version history

Assessors ask what changed between versions and who authorized the change. A policy copied into a document with no history cannot answer that. Keep policies in a system that records each change, the author, the date and the reason, and allows comparison and rollback. A wiki or documentation platform you host yourself can provide this, and the same record can serve as evidence for the approval, communication and review steps. Confirm that the platform's version history is retained for the period your auditor will sample.

Questions buyers ask about A.5.1 policies

How long does it take to build the information security policy set?

No researched figure exists for the duration, so plan from the work involved rather than a fixed number. The effort depends on how many topic-specific policies the scope needs, how much of the existing documentation can be reused, how many approvers sit in the chain, and how quickly management reviews drafts. Organizations with few systems and a small headcount usually finish faster than those with several business units, multiple legal entities or many regulatory obligations. Ask any partner for a written breakdown by policy, with named reviewers and a review schedule before work starts.

Can an in-house team write the A.5.1 policies without outside help?

Yes, an in-house team can write them, provided it has someone who understands the standard, the risk assessment and the business. The harder part is not drafting but getting approval, communicating the policies and keeping evidence that people acknowledged them. Teams often underestimate the time needed to align policies with actual practice, such as the access, incident and supplier processes that the policies describe. An outside partner can help with structure and templates, but the organization still owns the content and its approval.

What does management have to do for the policies to count?

Management must approve the information security policy and the topic-specific policies, so the approval must be visible and dated. Leaders must also make sure the policies are published, communicated to relevant personnel and interested parties, and acknowledged. Auditors look for evidence that management set the direction, allocated resources and reviewed the policies at planned intervals and after significant changes. The top-level policy duty sits in clause 5.2, so the policy approval chain should link to that clause and to the leadership responsibilities in clause 5.1.

Do the information security policies need to be certified?

No. ISO does not certify policies or documents. A certification body audits the management system, including whether the policies exist, were approved, communicated and reviewed, and it issues a certificate to the organization only if the ISMS meets the requirements. Accredited certification bodies must operate to ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024. Confirm the accreditation status of any body you engage through the IAF CertSearch database.

How often must the information security policies be reviewed?

The control requires review at planned intervals and after significant changes, but it does not set a fixed period. Organizations usually choose an annual cycle and document it in the policy itself, then add extra reviews after events such as a major incident, a merger, a new cloud platform or a change in law. Auditors check that the stated interval was followed and that each review left a record, including who reviewed it and what changed. Version control in a wiki or document system makes that history easier to show.

What can an implementation partner write for us, and what must stay with us?

A partner can draft policy templates, map policy statements to the Annex A controls, set up the approval workflow and publication, and prepare the evidence trail. The organization must decide the risk appetite, approve the content, name the owners and confirm that the policies match real practice. Independent auditors and certification bodies issue reports and certificates, so a partner must not present itself as the assessor. Ask for the written scope, the list of deliverables and who signs off each document before engagement starts.

How do we show auditors that staff read and acknowledged the policies?

Keep a dated record of publication and acknowledgement for each policy version, tied to the individuals who need it. Many organizations use a document platform with per-page version history and role-based permissions, so that the current policy is published in one place and older versions remain retrievable. Auditors will sample staff, including new joiners and contractors, and check that each person acknowledged the version in force at the time. Confirm that your chosen tool can export these records before you rely on it.

How A.5.1 differs from clause 5.2 and related controls

Clause 5.2 requires top management to set a top-level information security policy, while A.5.1 covers that policy together with the topic-specific policies beneath it. The clause 5.2 policy states the organization's intent and commitments in broad terms. A.5.1 asks whether the full set, including the topic-specific policies for areas such as access, supplier management and acceptable use, is approved by management, published, communicated to relevant personnel and interested parties, acknowledged by them, and reviewed at planned intervals and after significant changes. An auditor will usually check the two together, so the first decision is to agree the list of topic-specific policies and map each one to its owner, approver and review date. Confirm the exact wording of both requirements in the standard itself and in ISO/IEC 27002:2022, which gives the implementation guidance.

Three related controls test whether those policies are actually followed. A.5.4 Management responsibilities checks that managers require personnel to apply the policies and procedures, typically through briefings, acknowledgements and follow-through. A.5.36 Compliance with policies, rules and standards for information security checks that managers and technical compliance reviews regularly test adherence and act on findings. A.5.37 Documented operating procedures checks that the procedures behind the policies are written down, kept current and available where staff need them. An auditor will often sample one policy, then trace it forward to the acknowledgement records under A.5.4, the compliance review results under A.5.36 and the matching procedure under A.5.37. If any link is missing, the policy alone will not satisfy the assessment, so plan these records before the audit starts.

Version control is the practical evidence for A.5.1 review cycles. Tools such as XWiki keep every change to a page under version control, recording what changed, when and by whom, and allow comparison and rollback between versions. BookStack assigns user abilities through roles and can override permissions at the shelf, book, chapter or page level, which helps separate who may edit a policy from who may approve it. Whichever platform you choose, confirm that it can show approval history and acknowledgement records, not only edits, and decide who holds the approver role before the first review cycle begins.

How DeployOpen prepares A.5.1 policy evidence

DeployOpen plans, implements and documents the systems that hold an information security policy set and its topic-specific policies inside your own infrastructure. We prepare the approval, publication, acknowledgement and review records an assessor samples for A.5.1, while your organization owns the policies, their content and their approval. Certification decisions rest with an independent certification body.

How we scope

Agree in writing which policies sit under A.5.1, including the top-level policy and each topic-specific policy in scope
Confirm the named approvers, publication channel and acknowledgement population for each policy before work starts
Define the review interval and the triggers for out-of-cycle review, such as significant changes, agreed with your management

How we build

Set up a version-controlled policy repository on self-hosted wiki tooling that records authors, changes and approval history
Configure role-based access so that policy owners edit and staff can only read, with approvals captured in the page history
Build acknowledgement tracking and a review calendar that shows which policies are overdue for review

How we hand over

Deliver the policy set, approval and review records, and acknowledgement logs as documented evidence for your assessor
Provide a walkthrough so your policy owners can publish, review and retire policies without our involvement
Document the procedure for keeping the evidence current, so the trail stays intact between assessments

How we support

Support is available as a retainer for review cycles, platform upgrades and changes to the policy set
Re-run acknowledgement and review checks on a schedule agreed with your compliance lead
Confirm with your certification body which policy records they expect to see before the audit begins