What ISO 27001 A.5.4 management responsibilities requires in practice
Control A.5.4 asks management to require every person working for the organization to apply information security in line with the established information security policy, topic-specific policies and procedures. The requirement sits with management, not with the security team alone, so an auditor will look for proof that managers actually directed their staff to follow the rules. The risk it addresses is simple: people act outside security rules because nobody told them the rules applied to their work, or nobody checked that they did. A written policy that no manager has pushed down to a team does not meet this control, and a compliance lead facing an audit question should treat the question as one about direction and follow-through, not about document existence.
The difficulty is proving the chain from management instruction to personal behavior. Auditors typically ask for evidence that the expectation was communicated to all relevant personnel, including contractors where the scope requires it, that people acknowledged it, and that managers followed up when compliance fell short. Useful artifacts include signed or recorded acknowledgements, briefing attendance, manager objectives that include security responsibilities, and records of corrective action. Confirm with your certification body how it expects these records to be kept for your scope, because the form of acceptable evidence is decided by the auditor, not by the standard text.
A.5.4 is easy to confuse with two neighbors. Clause 5.1 of the standard sets top management's broader duties to demonstrate leadership and commitment to the ISMS, such as ensuring resources and objectives. A.5.4 is narrower and operational: it is about how each manager cascades the rules to their people. A.6.3 covers awareness, education and training, which is the content people learn. A.6.4 covers the disciplinary consequences of breaches. A practical test is to ask whether the evidence shows a manager directing a person to comply (A.5.4), a person learning how (A.6.3), and a defined consequence for non-compliance (A.6.4). Mapping each of these to a named owner prevents gaps between them.
Which people, roles and third parties A.5.4 covers
A.5.4 applies to everyone whose work touches information, but the boundary is set by your ISMS scope statement and Statement of Applicability, not by the org chart. The cards below cover the populations to decide on, the managers who enforce the requirement, and the evidence that grows with headcount.
Employees across all functions
Permanent staff are the core population, but scope decisions go beyond the security team. Engineering, finance, HR, sales and facilities staff all handle information, so each function's managers need to be named as responsible for applying the policy and procedures within their area. Check that your scope statement covers every business unit and location that the ISMS includes, and that none of them is silently left out of the briefing and acknowledgement process.
Contractors and temporary staff
Contractors and temporary staff often hold privileged access but sit outside the normal hiring and onboarding path. For A.5.4, the organization must still require them to apply the policy and topic-specific rules, which usually means written terms in their engagement contract and a briefing before access is granted. Confirm who sponsors each contractor, who tracks their end date, and how their acknowledgements are recorded.
Third parties with information access
Suppliers, consultants and outsourced staff who reach your information are not automatically bound by your internal policy. Their obligations usually come through supplier agreements under A.5.20 and access terms, so A.5.4 is met by requiring them to follow your rules where they use your systems or data. Ask which third parties your Statement of Applicability treats as in scope and which contract clauses or access agreements carry the requirement for each.
Managers as the enforcing layer
Managers are where A.5.4 is actually enforced, because they assign work, approve access requests and see whether staff follow procedures. Each manager should have documented responsibilities for briefing their team, confirming acknowledgements and raising non-compliance, and those duties belong in role descriptions. Check that managers know which policies apply to their teams and that escalation goes to a named owner when a breach is found.
Scope statement and Statement of Applicability
The scope of A.5.4 is not set by a separate list. It follows the ISMS scope statement, and the Statement of Applicability records that the control is applicable and how it is implemented. Before you collect acknowledgements, confirm that the scope statement, the SoA and the population list agree on who is covered, and record any exclusions with a justification that an auditor can follow.
Population size and evidence volume
The number of people in scope determines how much evidence the acknowledgement process needs and how hard it is to keep current. A small team can track acknowledgements in a single register, while a large or distributed population needs automated reminders, role-based assignment and periodic reconciliation against HR and access records. Ask your implementation partner or auditor how they will sample the population and what records they expect to see for each sampled person.
How an assessor tests management responsibilities
This table sets out each step an assessor takes to test A.5.4, the evidence requested at each step and the findings that most often lead to a nonconformity. Read it as a checklist: if your evidence cannot answer the question in the middle column, expect the assessor to ask for more before closing that step.
| Test step | What the assessor checks | Evidence requested | Common finding |
|---|---|---|---|
| Review the policy set | The information security policy and topic-specific policies explicitly require personnel to follow them, and management's role in that requirement is stated | Approved policy documents with version history and approval records | Policies say personnel must comply but never state management's duty to require it |
| Trace the requirement to management | Managers are named as the people who make compliance a condition of work, not only the security team | Manager briefing materials, role descriptions and escalation paths | Responsibility sits only with the security function, with no evidence line managers were briefed |
| Sample personnel | A sample of employees, including recent joiners and people in high-risk roles, has received and accepted the relevant policies | Signed or electronically recorded acknowledgements matched against the current staff list | Acknowledgements missing for some sampled staff, or only collected for the old policy version |
| Check contractors and third parties | Contractors, temporary staff and other personnel working under the organization's control are included in the same requirement | Contractor onboarding records, agreements referencing the policy and their acknowledgements | Contractors left out of briefings and acknowledgements because they sit outside HR records |
| Verify briefings and reinforcement | Staff were briefed when policies changed and receive periodic reminders, with attendance recorded | Briefing agendas, attendance logs, recordings and dates tied to policy versions | Briefings held once at onboarding and never repeated after material policy changes |
| Test objectives and follow-through | Management has set information security objectives for its areas and reviews progress against them | Dated objectives, review minutes, actions raised and closed | Objectives exist on paper but were never reviewed or updated |
| Review handling of non-compliance | Breaches are recorded, investigated and handled consistently, with the outcome linked to the disciplinary process | Records of non-compliance, decisions taken, and links to corrective actions | Repeated breaches with no recorded management response, or inconsistent outcomes between teams |
Steps to implement A.5.4 with a working evidence trail
This sequence turns A.5.4 from a statement in a policy into a set of owned responsibilities, briefed and acknowledged staff, measurable manager objectives and recorded follow-through that an assessor can sample. Each step produces a record the organization can show.
Confirm the policy set personnel must follow
Start by listing the information security policy and every topic-specific policy and procedure that staff are expected to apply, including the owner and current version of each. The output is a controlled policy index that the rest of the steps reference. Check that the index matches what is published on the intranet or wiki, because an assessor will compare the two. Done when every document has an owner, a version and a review date recorded.
Assign management owners for each department
Name a manager in each department who is accountable for making sure their team applies the policy set. Record the assignment in a responsibility matrix that lists the department, the named manager, the policies in scope and any areas where the manager relies on a specialist. The output is a signed or approved matrix held with the ISMS documentation. Confirm that each named person accepts the role in writing, since an unassigned area is a gap an auditor will find quickly.
Define the briefing and acknowledgement process
Decide how new joiners and existing staff are briefed on the policy set, how often briefings repeat, and what each person must sign or click to acknowledge them. Write the steps down as a short procedure so the process does not depend on one person's memory. The output is that procedure plus a template acknowledgement. Coordinate with the awareness and training controls so the briefing content and the training records do not contradict each other.
Run briefings and build the acknowledgement register
Deliver the briefings and collect acknowledgements from every person in scope, including contractors where they are subject to the same expectations. Keep the acknowledgement register in a system that records the person, the policy version acknowledged, the date and the method. A learning platform such as Moodle can mark an activity complete when a learner views it or ticks it, which can serve as a register if its completion conditions are configured to match the policy. Done when the register covers the full in-scope population, and gaps are followed up and recorded.
Set security objectives for managers
Agree a small number of information security objectives with each manager, tied to the policies their teams apply, such as completing access reviews on time or resolving audit findings in their area. Write each objective with a measure and an owner so progress can be checked later. The output is a signed objectives record per manager, kept with the performance evaluation materials. Confirm with the organization's HR and management system owners how these objectives are reflected in performance reviews, because that choice shapes how seriously managers treat them.
Review follow-through at planned intervals
At the intervals the organization sets, each manager reviews how their team is applying the policies, checks the objectives and records what was found and what will change. The review should look at evidence, such as access review outputs, incident records and exceptions, rather than rely on a verbal confirmation. The output is a dated manager review record for each department. Keep reviews in a versioned wiki or document system such as XWiki, where changes and earlier versions remain visible.
Record outcomes and feed them into corrective action
Bring the review records, acknowledgement gaps and missed objectives into a single list that the ISMS owner tracks to closure. Each item needs an owner, a decision and a closure record. Where a lapse involves a breach of policy, link it to the disciplinary process in A.6.4 rather than handling it informally. The output is a consolidated log that shows the cycle ran, what it found and how each finding was closed, which is the evidence an independent reviewer will sample.
Evidence that satisfies A.5.4 and how to keep it current
A.5.4 is proven by records, not by intent. An assessor will ask who received the policy, who was briefed, what managers were asked to do, and what happened when someone did not comply. The cards below cover the artifacts that answer those questions and the routines that keep them accurate between audits.
Signed policy acknowledgements
Each person who handles information should record, with a date, that they have read and agreed to follow the information security policy and the topic-specific policies that apply to their role. Check that the acknowledgement names the exact document version, not just the policy title, so you can prove which rules each person accepted. Sample a handful of personnel from different teams and confirm each one has a current acknowledgement on file.
Briefing attendance records
Briefings show management has told personnel what the policy requires and how it applies to their work. Keep the agenda, the date, the audience list and the material shown, and reconcile the attendee list against the current staff roster. Where a briefing is delivered as an online course, record completion through the learning platform and keep the completion rule that was in force at the time.
Manager objectives and review records
Managers should have information security responsibilities written into their objectives, such as ensuring their team completes acknowledgements or closes overdue access reviews. Record each objective, the review date and the outcome, and confirm the objective was assessed in the normal performance cycle. Ask the organization to confirm which objectives apply to which manager grades, since assessors often test a sample of managers rather than the whole population.
Management communications
Emails, intranet posts and leadership updates that restate security expectations show management is actively directing personnel. Store them in a controlled location with the sender, the date and the audience, and tie each one to the policy or procedure it reinforces. Versioned wiki pages help here because they show what changed, when and by whom, which matters when a policy is revised.
Re-acknowledgement after policy changes
When a policy or topic-specific policy changes materially, personnel should acknowledge the new version. Define the trigger in the policy itself, track which people are outstanding, and set a deadline for closing the gap. Keep the old acknowledgements so the record shows what each person agreed to at each point in time.
Joiner handling and records of action on non-compliance
New starters should receive the policy and sign their acknowledgement before or at the point they gain access to systems, and the onboarding checklist should show this step. When someone breaches the policy, record the finding, the management response and any disciplinary outcome, linked to the related control on disciplinary process. Auditors look for evidence that breaches led to follow-through, not only that rules exist.
How management follow-through becomes auditable
A.5.4 is about a chain: the information security policy is approved, communicated, acknowledged, reinforced by managers and then checked. An assessor does not accept a manager's statement that people were told to follow the rules. They look for a trail that links each manager's instruction to the policy and topic-specific policies, to the people who were expected to act on them, and to the follow-through that shows the expectation held. Each link needs its own record, and the weakest link is usually the last one, where a reminder given in a meeting never becomes anything an auditor can sample.
Consider an illustrative example. A department manager runs a quarterly review in which she confirms that each team member has acknowledged the current policy set, that the team's topic-specific procedures are the versions in the document store, and that open security actions from the last quarter are closed or re-dated with a reason. She records the attendees, the policy versions reviewed, and the actions in a dated note, and she links that note to the team's objectives. The record is modest, but it shows management requiring application of the policy, and it gives the A.5.36 compliance review a starting point it can test against.
Before relying on this chain, confirm three things with your own records. First, decide which policy versions each role must acknowledge and whether acknowledgements are kept per person and per version. Second, decide how managers' reviews are scheduled, who checks them, and where the notes live, so that the evidence is not scattered across email. Third, confirm that the findings from reviews feed the corrective actions tracked under your ISMS. Open-source tools can hold parts of this trail. Moodle's activity completion can record when a learner has viewed or completed a policy module, XWiki keeps version history for policy and procedure pages, and BookStack's role-based permissions can limit who edits them. Confirm each platform's behavior in your own environment before treating its records as evidence.
What meeting A.5.4 costs in money and effort
This table breaks down the cost of meeting A.5.4 into its components, showing who carries each one, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote and budget, since no supplied figures set the amounts. The main takeaway is that most of the cost is management and staff time, so tooling choices change the license line but not the effort.
| Cost component | One-time or recurring | What drives it |
|---|---|---|
| Management time for briefings and objectives | Recurring | Number of managers, briefing frequency and how objectives are set and tracked |
| Designing the acknowledgement workflow | One-time, with later changes | Whether HR, IT or a self-hosted learning platform records acknowledgements, and how many policies need sign-off |
| Engineering or HR build effort | One-time | Integration with identity and HR systems, and whether the workflow is built in-house or by an implementation partner |
| Ongoing evidence upkeep | Recurring | Joiner and leaver volume, policy revision frequency and how many topic-specific policies must be re-acknowledged |
| Staff turnover and new-hire onboarding | Recurring | Headcount growth and turnover rate, since every new starter must receive briefings and acknowledge policies |
| Licence spend on tools | Recurring if commercial, near zero for self-hosted open source | Per-user pricing on commercial learning or GRC tools versus hosting and maintenance of open-source platforms |
| Hosting and maintenance of self-hosted tools | Recurring | Infrastructure location, backup and upgrade routines, and who is responsible for patching |
| External review of the workflow | Periodic | Scope of the review, whether it is an internal audit or an outside readiness check, and the size of the ISMS |
| Auditor sampling time | Each audit cycle | How many personnel and acknowledgements the auditor samples and how quickly the organization can produce records |
Who owns A.5.4 and what a partner can take on
Management owns A.5.4 in the sense that it cannot be delegated away. Senior leaders decide that every person in scope must apply the information security policy, topic-specific policies and procedures, and they are accountable when managers do not enforce that expectation. Management also sets the objectives that give the requirement meaning, such as which teams must complete briefings and how security responsibilities feed into performance conversations. An implementation partner can draft these materials, but the decisions, the signatures and the follow-through stay inside the organization.
- Setting the expectation: Approve the briefing content, the required acknowledgements and the consequences of non-compliance, and record that approval in the management review minutes.
- Owning objectives: Assign security objectives to department heads and confirm they are reviewed at a set interval, not only when an audit is approaching.
- Enforcing and attending: Require managers to escalate missed briefings or unsigned acknowledgements, and attend the sessions where senior leaders are expected to speak.
- Acting on gaps: Decide how repeated non-compliance is handled, in line with the disciplinary process in A.6.4.
Check that each named manager can explain their objectives and show the last time they followed up on a gap.
An implementation partner prepares the systems and records that let management's expectations be demonstrated. In practice this is the acknowledgement workflow, the briefing templates, the tracking of who has completed what and the document trail that links a policy version to the people who read it. DeployOpen works this way: it plans, configures and documents self-hosted open-source platforms inside the client's own infrastructure and prepares the evidence, while the organization keeps ownership of the content and decisions. Partners are usually engaged on a fixed scope, with deliverables and timelines agreed in writing before work starts.
- Acknowledgement workflow: Configure a platform so each person in scope is assigned the current policies and must confirm them, with a record of when and what they accepted.
- Templates and briefings: Prepare briefing materials and onboarding procedures that the organization reviews and approves, rather than writing policy positions on its behalf.
- Evidence trail: Set up version history so that every change to a policy or procedure is recorded with what changed, when and by whom.
- Completion reporting: Produce reports that show completion rates by team and flag overdue items for managers.
Before engaging, confirm in writing which artifacts the partner produces and which the organization must approve or sign itself.
The auditor tests whether A.5.4 operates in practice. Accredited certification bodies work to ISO/IEC 17021-1:2015 with ISO/IEC 27006-1:2024, and they must be independent of the organization and of any consultant that helped prepare it. An auditor typically samples people across roles and teams, asks them what they were told and what they agreed to, and compares the acknowledgement records with the current policy version. Only an independent auditor or certification body issues findings, reports or certificates. DeployOpen prepares systems and evidence for an assessment but does not issue audit reports, attestations or certifications.
- Sampling: Select personnel across functions, including recent joiners and people in high-risk roles, and check their acknowledgement records.
- Version matching: Confirm that the acknowledgement refers to the policy version in force at the time.
- Findings: Record nonconformities where briefings were missed, acknowledgements were absent or objectives were never reviewed.
- Independence: Expect the auditor to decline to design the controls it later tests.
Ask any certification body how it handles prior consulting work and which evidence it will request during the audit.
Where A.5.4 gaps usually appear and how to close them
A.5.4 is tested through records, not intentions. The gaps below recur across assessments because they sit where policy meets daily work: contractors, managers, policy changes, non-compliance and scattered evidence. Each card names the check an assessor is likely to make and the step that closes the gap.
Policies not acknowledged by contractors
Employees often sign policy acknowledgements at onboarding, while contractors, agency staff and temporary workers slip through because they are not in the HR system. A.5.4 applies to all personnel working under the organization's direction, so contractors need the same briefing and a signed or recorded acknowledgement before access is granted. Check whether your contractor onboarding path includes a policy step and whether the record links to the access request. Illustrative example: a contractor with production access and no acknowledgement on file is an easy finding to raise.
Managers without documented objectives
Management is expected to direct personnel to follow security policy, so an assessor will ask how managers set and track that expectation for their teams. Many organizations have a policy but no written security objective for the people who lead teams, which leaves the requirement with no owner. Add a security line to manager objectives or role descriptions, and keep the dated record that shows the objective was set and reviewed. Confirm the objective is written in a place the assessor can actually open.
Acknowledgements not repeated after policy changes
An acknowledgement signed against an old policy version does not show that personnel apply the current one. When the information security policy or a topic-specific policy changes, the organization should re-brief affected people and record fresh acknowledgements against the new version. Make the version number part of the acknowledgement record so the link is provable. Check how many policy revisions occurred in the last year and whether each one triggered a recorded re-briefing.
No record of non-compliance follow-up
When personnel break a security rule, A.5.4 expects management to act, and the disciplinary process in A.6.4 is one route. Auditors look for the trail: what was observed, who was informed, what action was taken and whether the behavior changed. Without that trail, the organization cannot show that management responds to breaches. Record each finding with an owner, a decision and a closure date, and review the log at management meetings.
Evidence scattered across email
Briefings, approvals, objectives and warnings often live in individual inboxes, so the organization cannot show a complete picture when an assessor asks for samples. Centralize the records in one controlled location with restricted edit rights and version history, such as a wiki or document system with change tracking. Choose a single system of record for acknowledgements and objectives, then tell managers where each record belongs. Confirm that the system keeps who changed what and when, since that history is what the assessor will test.
Questions buyers ask about A.5.4 cost, time and ownership
How much effort does A.5.4 take compared with A.6.3?
A.5.4 usually takes less standalone effort than A.6.3, because it asks management to require that personnel follow the policies and procedures, while A.6.3 asks for a working awareness, education and training programme. Most of the A.5.4 work is internal and recurring: issuing the policy set, briefing managers, collecting acknowledgements and setting objectives that managers actually track. A.6.3 needs training content, delivery, attendance records and refresher cycles, which often means buying or building courses. The effort for either control depends on headcount, how many topic-specific policies exist and how many managers must be briefed. Ask any consultant to estimate both controls separately, with the assumptions written out, before you compare them.
Can a small company run A.5.4 in-house?
Yes, in most cases a small company can run A.5.4 in-house, provided one person owns the policy set and every manager accepts a clear role in enforcing it. The control is about management requiring compliance, so the core tasks are short: name the policies that apply, brief each manager, record that each person has read and acknowledged them, and review the objectives at a set interval. The harder part is consistency. A small team can drift when founders or leads do not reinforce the rules, so an auditor will look for proof that management followed through, not only that a policy exists. An external partner is most useful for the first setup and the evidence design, not for daily operation.
What does A.5.4 need from managers?
A.5.4 needs managers to take active, documented responsibility for how their teams apply information security. In practice this means managers must receive the policy set, explain the relevant rules to their staff, confirm that new joiners and movers are briefed, and raise non-compliance through the disciplinary route when needed. Managers also feed into objectives, so each team should have security goals that appear in its planning. Auditors commonly ask a manager to explain what they require from their team and to show how they checked it. Confirm with your certification body how much manager-level evidence it expects for your scope, because practice varies between assessors.
How long does a readiness exercise for A.5.4 take?
No researched figure is available for how long an A.5.4 readiness exercise takes, so treat any duration you hear as unverified. The time depends on the number of policies that need management sign-off, the number of managers and sites, whether acknowledgement records already exist and how much the current practice differs from the written requirement. Ask a prospective partner for a written scope that lists the policies reviewed, the managers interviewed, the evidence samples checked and the deliverables, then compare timelines against that scope. You can also run a short internal gap check first to size the work.
Will an auditor accept email as evidence for A.5.4?
An auditor may accept email as evidence for A.5.4, but only if the email is a reliable, dated record of the management action it claims to show. A message from a manager that instructs a team to follow a named policy, sent to a defined group, can support the control. Weak evidence includes unattributed messages, forwarded copies with no original timestamp or emails that announce a policy without any proof that people read it. Stronger practice is to keep policies and acknowledgements in a version-controlled system, such as the wiki or document platform your organization runs, so the reviewer can see who approved what and when. Confirm the acceptable evidence format with your certification body before you rely on email.
When should an organization bring in a partner for A.5.4?
Bring in a partner when the organization needs help designing the management responsibility process, building evidence that holds up to assessment, or setting up self-hosted tools that record acknowledgements and objectives. DeployOpen plans, implements and documents self-hosted open-source platforms in the client's own infrastructure and prepares systems and evidence for compliance assessments, but it does not issue audit reports or certificates; an independent auditor or certification body does that. Most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts, and a quote follows from that written scope. Keep ownership of the policies and manager accountability inside the organization, because the control only works if managers own it.
Using self-hosted tools to record acknowledgements and objectives
A.5.4 is tested largely through records: an auditor wants to see that personnel were told about the information security policy and topic-specific policies, that they acknowledged them, and that management's objectives were set and followed up. Self-hosted open-source tools can hold each of these records inside your own infrastructure. In Moodle (GPL-3.0-or-later), activity completion can mark a policy briefing as complete for each learner when they view it, when they receive a grade from it, or when they tick it manually, depending on the conditions you set. Pick the condition deliberately. Viewing alone proves a page was opened, not that the person understood it, so for a policy most organizations pair the briefing with a short quiz or a signed manual tick. Export the completion report at each review date and keep it with the policy version it refers to.
XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back. This is the evidence that shows how a policy or a management statement evolved, and who approved the wording that was in force on a given date. Confirm with your own process that the approver's sign-off is recorded in the page itself or in a linked approval record, because version history shows who edited, not who authorized. BookStack (MIT) handles objectives differently: user abilities come from assigned roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Use this to let only the named management owners edit the objectives page while every employee can read it. Test the permission model with a non-owner account before you rely on it.
Confirm three things before adopting this setup: that the license terms (GPL-3.0-or-later, LGPL-2.1-or-later and MIT) fit how you will deploy and modify each tool, that your own policy approval and acknowledgement process matches what the tools record, and that your retention rules for completion data and page history meet your records obligations. The tools produce records; they do not decide whether management's follow-through is adequate, and an independent auditor will still judge that. Your implementation partner can configure and document these tools, but the organization owns the policy, the objectives and the decisions recorded in them.
How DeployOpen prepares A.5.4 evidence in your environment
This sequence turns the management responsibility for A.5.4 into a written scope, configured self-hosted platforms, reusable templates and evidence that an independent assessor can sample. DeployOpen prepares the systems and records, while the organization owns its controls and an independent auditor or certification body issues any report or certificate.
Agree the scope and owners in writing
Before work starts, DeployOpen and your team agree in writing which policies, topic-specific policies and procedures management must cascade, which business units and personnel groups they cover, and which named managers own each requirement. Your organization stays accountable for the control. The output is a signed scope statement with a named owner for A.5.4 and a list of the personnel populations it reaches, including contractors and other external personnel where your policy applies to them. Confirm the scope with your certification body or assessor early if you expect an assessment.
Confirm the policy baseline to cascade
DeployOpen reviews the information security policy and the topic-specific policies that managers must enforce, checking that each has an approver, a version and a review date. Gaps are logged, and your policy owner decides how they are closed. The output is a baseline document that lists each policy, the procedures beneath it and the manager responsible for applying it in their area. Because the policy itself is covered under A.5.1, this step only confirms that the baseline is complete enough to cascade.
Configure the self-hosted wiki for policy publication
DeployOpen installs or configures a self-hosted documentation platform inside your infrastructure, such as XWiki or BookStack, so policies and procedures have one controlled location. Open-source wiki platforms can keep a version history that records what changed, when and by whom, and let reviewers compare versions and roll back. Access is set through roles so that only authorized editors can change management-approved documents. The output is a published policy space and a tested rollback, which you confirm by checking the version history of a sample page against your own change process.
Build briefing and acknowledgement tracking
DeployOpen sets up a course or acknowledgement workflow, for example in a self-hosted learning platform such as Moodle, that presents the policy briefing to each personnel group and records completion. Activity completion can be configured to mark an item complete when a learner views it, receives a grade or ticks a confirmation, depending on the conditions you set. The output is a tested workflow with one record per person and per policy version. Confirm with your HR and legal teams that the acknowledgement wording matches your employment terms before rollout.
Define objectives and manager follow-up
Your managers, with DeployOpen providing templates, record how they will apply the policy in their teams: the security responsibilities of each role, the procedures staff must follow and the checks they will run. Objectives and follow-up actions are logged against each manager. The output is a set of manager review templates and a register of actions with owners and status. DeployOpen does not set the objectives for your business; these come from your leadership and management.
Set up compliance review and exception records
DeployOpen configures a recurring review, with reminders, in which managers confirm that their teams apply the policy and procedures, and records any exceptions with approval and a remediation date. Where your tooling supports it, reviews link to the evidence they rely on. The output is a dated review record per manager and a log of exceptions. Confirm the review frequency with your policy owner, since the cycle is set by your organization rather than by the standard.
Assemble the evidence pack for assessment
DeployOpen compiles the evidence an assessor will sample: the approved policies and their version history, the acknowledgement records, manager reviews, objectives, exception logs and the actions that followed each finding. Records are organized by period so an assessor can select a sample across the audit window. The output is an indexed evidence pack and a short guide that explains where each record lives. Your team checks that the pack reflects what really happened in your organization, since an assessor will test that the records match practice.
Hand over to the independent assessor
DeployOpen delivers the configured systems, templates, evidence pack and handover notes to your team and, where you choose, to the auditor or certification body you have engaged. DeployOpen does not issue audit reports, attestations or certifications. Only the independent auditor or certification body can assess conformity and issue a report or certificate. The output is a signed handover record that lists the deliverables and open items, which your organization retains as the basis for its own assessment.
