Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Starter Kit · Policy

ISMS Governance Policy

Updated on 7 min Reviewed by: Cenedril Editorial
A.5.1A.5.35A.5.36A.5.37 ISO 27001BSI ISMS.1BSI DER.3.1

The ISMS Governance Policy governs how all ISMS documents are created, approved, distributed, reviewed and archived. Without this document, the entire management system lacks a traceable foundation — and in an audit, it comes down to one person’s word against another’s.

Three Annex A controls form the backbone: A 5.1 (Policies for Information Security), A 5.36 (Compliance with Policies, Rules and Standards) and A 5.37 (Documented Operating Procedures). BSI IT-Grundschutz requires an information security policy in ISMS.1.A3, clear responsibilities and regulations in ORP.1.A1, maintenance of information security in ISMS.1.A11 and a structured audit programme in DER.3.1. Further down you will find the complete template in English and German.

What does it actually cover?

Every ISMS produces documents: policies, procedures, risk registers, audit reports, training records, incident logs. The policy governance framework defines the rules for this entire body of documentation — from creation through approval to archiving and eventual disposal.

In practice, without clear rules the picture looks like this: three versions of the same policy circulate simultaneously, nobody knows which one is current. Top management signed off on version 1.0, but IT has been working with an informal update for months. In an audit, there is no evidence that employees are even aware of the current version.

The document hierarchy creates order. At the top sits the overarching Information Security Policy with strategic direction. Below it are topic-specific policies (access control, cryptography, physical security, etc.), each governing a specific security domain in detail. On the third level sit management documents such as the risk register, the treatment plan, the audit programme and the information security objectives. At the bottom are operational records — everything generated by day-to-day operations: incident reports, training evidence, change tickets, management review minutes.

Why does it matter so much?

Foundation for every other policy. Document control defines how policies are created, approved, communicated and reviewed. Every other policy in the ISMS — from access control to cryptography — relies on this framework. When document control is missing or weak, every single policy lacks formal legitimacy.

Audit relevance in every certification audit. Auditors frequently start with document control because it lets them assess the consistency of the entire ISMS from one vantage point. Are policies current? Do approval records exist? Can employees confirm they are aware of the policies? These questions target A 5.1 and A 5.36 directly.

Operational consistency through A 5.37. Documented operating procedures ensure that critical tasks are performed the same way by different people. Backup procedures, incident response workflows, system restart sequences after outages — all of this must be documented so it works reliably even under pressure.

What goes into it?

The template covers five core areas:

  • Information security policies (A 5.1) — document hierarchy, content and structure of the overarching policy, approval by top management, review cycles and triggers, communication and acknowledgement, exemption handling
  • Compliance monitoring (A 5.36) — verification through internal audits and management reviews, documentation register with status tracking, handling of non-conformities (root cause analysis, corrective actions, effectiveness verification)
  • Documented operating procedures (A 5.37) — when a documented procedure is required (standardised, infrequent, risk-critical activities and personnel handovers), minimum content per procedure, change management for procedures
  • Records and evidence — audit reports, incident logs, training records, management review minutes, risk assessments, workflow records, assessment evidence, policy acknowledgement records
  • Retention and obsolete documents — minimum retention periods, alignment with the legal register and retention plan, marking and archiving of obsolete versions

How to roll it out

  1. 01

    Map your document landscape

    Before you write the policy, you need an overview of the current state. Which policies, procedures and records already exist? Where do they live — in a wiki, on a network drive, in email attachments? Who last updated them, and is there any approval record at all? This inventory shows you which documents are missing, which are outdated and where the biggest gaps lie.

  2. 02

    Define the document hierarchy and roles

    Assign every existing and planned document to a level in the four-tier hierarchy. For each document, determine the owner (responsible for keeping it current), the approver (top management, department head or ISB) and the review cycle. The result is a documentation register — a table with document name, hierarchy level, owner, approver, version, last review date and next review date.

  3. 03

    Adapt the template

    Our template has placeholders like [YOUR_ORGANISATION_NAME] and [POLICY_OWNER_ROLE]. Replace them. Check the six review triggers and remove any that are irrelevant in your context — or add industry-specific triggers. Retention periods must be aligned with your legal register; the template sets minimum periods, but statutory requirements (e.g. local commercial code, tax regulations) take precedence.

  4. 04

    Get approval and communicate

    The overarching Information Security Policy is approved by top management. For the document control policy itself, the ISB role is typically the approver. After approval, communicate the policy to all affected personnel — with a request for acknowledgement. Schedule training sessions for document owners: they need to understand how the approval and review process works.

  5. 05

    Operationalise the review cycle and compliance monitoring

    Enter the review dates for all documents into a central calendar. Define how non-conformities are detected and handled: who checks compliance? How are corrective actions documented and tracked? The policy defines the framework — now you need the operational backbone that ensures reviews actually happen and results feed into the next audit cycle.

Where it goes wrong in practice

From audit experience, sorted by frequency:

1. Policies without approval records. The document exists, but nobody can demonstrate when and by whom it was approved. In an audit, there is no evidence that top management or the appropriate management level authorised the content. An approval record with date, name and role belongs in every document.

2. Outdated versions in circulation. The current policy sits in the wiki, but three departments are working from a PDF copy that is two years old. Without centralised distribution and version control, this is inevitable. The fix: a single authoritative location with automatic notification when new versions are published.

3. Reviews that exist only on paper. The policy says “annual review,” but the review record consists of a tick next to the date. Auditors expect evidence that the content was actually examined and updated where necessary — review comments, a change history, or at minimum a documented conclusion stating “no changes required because XY.”

4. Missing acknowledgement records. The policy was published, but there is no evidence that affected personnel read and acknowledged it. This is especially problematic for new employees whose onboarding process does not include policy acknowledgement.

5. Operating procedures that live only in people’s heads. Backup procedures, incident response workflows, system restart sequences — all passed on verbally. As long as the one person who knows the process is available, it works. The moment they are unavailable, there is no fallback. A 5.37 exists for exactly this situation.

Template: ISMS Governance Policy

Full policy text

ISMS Governance Policy

.md · EN.md · DE

Document control
Owner: [POLICY_OWNER_ROLE, e.g. Information Security Officer]
Approved by: [APPROVER_NAME_AND_ROLE]
Version: [VERSION]
Effective date: [EFFECTIVE_DATE]
Next review: [NEXT_REVIEW_DATE]

1. Legal/Regulatory Basis

ISO/IEC 27001:2022 / ISO/IEC 27002:2022, Annex A:

  • A 5.1 — Policies for Information Security
  • A 5.36 — Compliance with Policies, Rules and Standards for Information Security
  • A 5.37 — Documented Operating Procedures

BSI IT-Grundschutz:

  • ISMS.1.A3 (Information Security Policy)
  • ORP.1.A1 (Responsibilities and Regulations)
  • ISMS.1.A11 (Maintaining Information Security)
  • DER.3.1 (Audits and Revisions)
  • OPS.1.1.1.A3 (Operational Handbooks)
  • OPS.1.1.1.A7 (Orderly IT Operations)

Additional jurisdiction-specific laws and regulations — in particular records retention law (e.g. German HGB §257, tax code §147) and data protection law — are listed in the Legal Register and incorporated by reference.

2. Purpose & Scope

This policy establishes the framework for creating, approving, distributing, reviewing and maintaining all documented information within the Information Security Management System (ISMS) of [YOUR_ORGANISATION_NAME]. It ensures that policies, procedures, records and other documented information are controlled, current, accessible and traceable.

The policy applies to all ISMS documentation. The document hierarchy consists of the Information Security Policy and the Risk Management Policy at the top, followed by topic-specific policies covering individual security domains, supporting management documents (Asset Management, Corrective Actions & Improvement Register, Information Security Objectives, Stakeholder Register, Communication Plan, Internal Audit Programme, Audit Schedule) and operational records generated by day-to-day processes. All personnel responsible for creating, reviewing, approving or maintaining ISMS documentation are bound by this policy.

3. Information Security Policies (A 5.1)

The information security policy and all topic-specific policies are defined, approved by management, published, communicated to relevant personnel and interested parties, acknowledged by recipients, and reviewed at planned intervals and when significant changes occur. The policy framework is structured as a document hierarchy with clear ownership, approval authority and review responsibilities at each level.

3.1 Policy Considerations

The information security policy takes into consideration the following inputs:

  • Business Strategy & Requirements: The information security policy reflects the current business strategy, operational objectives and commercial requirements. Security controls are aligned with business priorities and resource constraints.
  • Regulations, Legislation & Contracts: The policy incorporates all applicable regulatory, statutory, legislative and contractual requirements. A legal register is maintained and referenced to ensure ongoing compliance.
  • Current & Projected Risks: The policy accounts for both current information security risks identified through risk assessment and projected threats derived from threat intelligence and industry trend analysis.

3.2 Policy Content Requirements

The information security policy contains the following elements:

  • Definition of Information Security: The policy provides a clear, organisation-specific definition of information security encompassing the protection of confidentiality, integrity and availability of information assets.
  • Objectives Framework: The policy establishes a framework for setting measurable information security objectives that are reviewed annually and aligned with the risk assessment results.
  • Guiding Principles: Core principles are stated that guide all information security activities: risk-based decision making, defence in depth, least privilege, separation of duties and continual improvement.
  • Commitment to Requirements: The policy includes an explicit commitment to satisfy all applicable legal, regulatory, contractual and self-imposed requirements related to information security.
  • Commitment to Continual Improvement: The policy includes a commitment to the continual improvement of the ISMS through the Plan-Do-Check-Act cycle.
  • Role Assignments: Responsibilities for information security management are assigned to defined roles. The RACI matrix documents accountability, responsibility, consultation and information flows for each ISMS activity.
  • Exemptions & Exceptions: A formal exemption request process is provided. Each exemption request captures the affected policy or control, justification, risk analysis, compensating controls and expiry date. The relevant risk owner is consulted for input, but the Information Security Officer is the sole formal approver to ensure a single accountable decision point. Exemptions are monitored during their validity and closed at expiry or earlier.

3.3 Document Hierarchy & Topic-Specific Policies

The Information Security Policy is supported by topic-specific policies that provide detailed requirements for each security domain. Several related domains are addressed in consolidated policies: incident management, technical vulnerabilities, change management and supplier reviews are covered by the Security Operations Policy; backup, networking, logging, monitoring and operational IT are combined in the IT Operations Policy. Asset management is documented in an Asset Management register rather than as a dedicated topic-specific policy. The following topics are in scope of the policy framework:

  • Access control
  • Physical and environmental security
  • Asset management
  • Information transfer
  • Secure configuration and handling of user endpoint devices
  • Networking security
  • Information security incident management
  • Backup
  • Cryptography and key management
  • Information classification and handling
  • Management of technical vulnerabilities
  • Secure development

Additional topic-specific policies cover human resource security, remote working, supplier security, business continuity, secure project management, data protection, intellectual property, configuration management and risk management. Each topic-specific policy references the applicable ISO 27001 Annex A controls and BSI IT-Grundschutz Bausteine.

3.4 Approval & Authorisation

  • Information Security Policy: The overarching information security policy and any amendments to it are approved by top management before publication.
  • Topic-Specific Policies: Each topic-specific policy is approved by the appropriate level of management with the authority and technical competency for the respective domain. The approver is documented in the policy metadata.

3.5 Review & Update

Policies are reviewed at least annually and additionally when triggered by specific events. Review responsibility is allocated to personnel with the appropriate authority and technical competency for the policy domain.

Review triggers:

  • Business Strategy Changes: When the organisation's business strategy, objectives or operating model change significantly.
  • Technical Environment Changes: When new technologies, platforms or architectures are introduced or existing systems undergo major changes.
  • Regulatory Changes: When applicable laws, regulations, statutes or contractual obligations change.
  • Risk Landscape Changes: When new information security risks are identified or the severity of existing risks changes materially.
  • Threat Environment Changes: When the threat landscape evolves, including emerging attack techniques, new threat actors or sector-specific advisories.
  • Lessons Learned: When information security events or incidents reveal gaps in policy coverage or effectiveness.

Review inputs:

  • Management Review Outputs: Decisions and action items from management reviews that affect policy content or scope.
  • Audit Findings: Internal and external audit results that identify policy gaps, ambiguities or non-compliance.
  • Related Policy Updates: Changes to other policies within the ISMS that create dependencies or conflicts with the policy under review.

3.6 Communication & Acknowledgement

Policies are communicated to all relevant personnel and interested parties in a form that is accessible and understandable to the intended audience. Recipients are required to acknowledge that they have read, understood and agree to comply with the applicable policies. The following communication methods are used:

  • Digital Distribution & Acknowledgement: Policies are distributed electronically and signed using a policy acknowledgement mechanism with auditable evidence (e.g. eIDAS-compliant signatures with one-time-password verification, document hash and audit trail). Signed acknowledgements are persisted as policy acknowledgement records and linked to the onboarding process so that every new employee acknowledges the applicable policies during onboarding.
  • Briefings & Meetings: Key policy changes are communicated in team meetings, onboarding sessions and annual awareness briefings. Attendance records serve as acknowledgement evidence for meeting-based communication.

4. Compliance with Policies, Rules & Standards (A 5.36)

Compliance with the information security policy, topic-specific policies, rules and standards is verified primarily through internal audits and management reviews. Policy completeness, approval status and review timeliness are tracked via a documentation register that flags missing approvals, outdated versions and language gaps. Whether the rules are actually lived in day-to-day operations is assessed through manual review during internal audits and management reviews, supported by metrics from operational tickets, incident records and vulnerability management. Compliance verification relies on the manual review cycles described above; automated measurement of operational control effectiveness beyond documentation completeness is not assumed.

4.1 Non-Compliance Response

When non-compliance is found as a result of a compliance review, the following steps are taken:

  • Root Cause Analysis: When non-compliance is identified, the causes are investigated to determine whether the issue stems from a policy gap, a process failure, a training deficiency, a resource constraint or wilful disregard.
  • Corrective Action Planning: The need for corrective action is evaluated based on the severity, scope and risk impact of the non-compliance. Corrective actions are documented with responsible owners, timelines and expected outcomes.
  • Corrective Action Implementation: Appropriate corrective actions are implemented to address the root cause and prevent recurrence. Actions range from process adjustments and additional training to technical remediation and policy clarification.
  • Effectiveness Verification: Corrective actions are reviewed to verify their effectiveness and to identify any remaining deficiencies or weaknesses. Verification is conducted after a defined period and documented with evidence.

Compliance review results and all corrective actions are recorded and retained as documented information. Managers report these results to the persons conducting independent reviews (internal audits) when such reviews take place in their area of responsibility. Corrective actions are completed in a timely manner appropriate to the risk. If a corrective action is not completed by the next scheduled review, progress is documented and addressed at that review.

5. Documented Operating Procedures (A 5.37)

Operating procedures for information processing facilities are documented in operational handbooks and made available to all personnel who need them. Procedures ensure the correct, consistent and secure operation of information processing systems.

5.1 When Procedures Are Required

Documented operating procedures are prepared for the following situations:

  • Standardised Activities: Activities that are performed by multiple people and need to be executed consistently follow documented procedures to ensure uniform execution and prevent deviations.
  • Infrequent Activities: Activities performed rarely are documented so that the correct procedure is available when the activity is next required, even if the original operator is no longer available.
  • Risk-Critical Activities: New activities or changes to existing activities that present a risk if performed incorrectly are documented before first execution. The documentation includes preconditions, step-by-step instructions and verification checks.
  • Personnel Handover: When activities are transferred to new personnel, documented procedures ensure continuity of knowledge and consistent execution during the transition period.

5.2 Procedure Content Requirements

Each operating procedure specifies the following elements as applicable:

  • Responsible Persons: Each procedure identifies the responsible person or role, including required competencies and authorisation level.
  • Installation & Configuration: Procedures for the secure installation and configuration of systems document baseline settings, hardening requirements and verification steps.
  • Information Processing: Both automated and manual processing and handling of information follow documented procedures that specify input validation, processing steps and output verification.
  • Backup & Resilience: Backup procedures define scope, schedule, method, storage locations and restoration testing requirements. Resilience procedures address failover and recovery steps.
  • Scheduling & Dependencies: Procedures specify scheduling requirements and document interdependencies with other systems, including the sequence of operations and timing constraints.
  • Error Handling: Instructions for handling errors, exceptions and unexpected conditions include diagnosis steps, escalation paths and recovery procedures.
  • Support & Escalation Contacts: Each procedure lists internal support contacts and external support contacts (vendors, service providers) with escalation paths for unexpected operational issues.
  • Storage Media Handling: Procedures for handling storage media cover classification-appropriate storage, transport, sanitisation and disposal requirements.
  • System Restart & Recovery: Recovery procedures for system failures document the restart sequence, integrity checks, data verification steps and service restoration confirmation.
  • Audit Trail & Log Management: Procedures for managing audit trails, system logs and monitoring records define retention periods, access controls, integrity protection and archival methods.
  • Monitoring Procedures: Capacity, performance and security monitoring procedures specify what is monitored, the monitoring tools used, threshold definitions, alerting rules and response actions.
  • Maintenance Instructions: Scheduled and ad-hoc maintenance procedures include pre-maintenance checks, maintenance windows, change approval requirements, rollback plans and post-maintenance verification.

Documented operating procedures are reviewed and updated when needed. Changes to procedures are authorised by the responsible person or role. Where technically feasible, information systems are managed consistently using the same procedures, tools and utilities to reduce configuration drift and operator error.

5.3 Records & Evidence

Records generated by ISMS processes are retained as documented information to provide evidence of conformity and effective operation. The following categories of records are managed:

  • Audit Records: Internal audit reports are created as records linked to each audit event, based on the Internal Audit Programme. External audit reports (certification audits, third-party audits, customer audits) are documented with auditor, framework, audit period, findings by severity, certificate details and executive summary. Corrective actions resulting from audits are tracked in the Corrective Actions & Improvement Register.
  • Incident Records: Security incident reports, investigation findings, evidence with chain of custody and post-mortem analyses are maintained by the incident management process.
  • Training Records: Training completion is captured per user, including module, completion date, score and duration. These records serve as training evidence; competence is verified through assessments at the end of each training module.
  • Management Review Records: Management review meetings capture minutes, decisions, action items, KPI snapshots and follow-up status.
  • Risk Records: Risk assessments, treatment plans and residual risk acceptances are maintained in the risk register. Point-in-time snapshots of the risk register are produced at each management review and internal audit cycle.
  • Workflow Records: Completed operational tickets serve as approval and change records. In particular, Change Management tickets capture the change request, impact assessment, approval, implementation evidence and post-implementation notes as structured records. Tickets are retained as documented information and made available for audits on request.
  • Assessment Records: Completed checklists, self-assessments and responses (including remote workplace assessments, project security assessments and decommissioning checklists).
  • Policy Acknowledgement Records: Signed policy acknowledgements produced via the acknowledgement mechanism (see Section 3.6).

5.4 Retention & Obsolete Documents

Documents and records are retained for a minimum period consistent with applicable statutory, regulatory and contractual requirements. The retention defaults are reviewed against the Legal Register and the data retention plan; longer statutory periods take precedence where they apply. Retained documents and records remain queryable for audit and historical reference even after being marked obsolete.

Obsolete versions are also marked explicitly by document owners when a newer approved version supersedes the previous one. Newer approved versions take precedence in the documentation view. Obsolete versions remain visible in the version history so that the audit trail is preserved.

6. Roles & Responsibilities

  • Top Management: Approves the Information Security Policy and ensures adequate resources are allocated for documentation activities. Bears overall accountability for the ISMS documentation framework.
  • Information Security Officer (ISO): Maintains the documentation framework, coordinates policy reviews, monitors document completeness and reports documentation status to management. Acts as the sole formal approver for exemption requests.
  • Data Protection Officer (DPO): Reviews documentation for data protection compliance and advises on retention requirements for records containing personal data.
  • Document Owners: Each policy and procedure has a designated owner responsible for keeping the document current, initiating reviews and processing change requests. Owners ensure their documents reflect current practices and requirements.
  • Reviewers & Approvers: Review documents for accuracy, completeness and compliance before approval. Approvers authorise publication of new or updated documents.
  • All Employees & Contractors: Read, understand and acknowledge applicable policies and procedures. Report documentation gaps or inaccuracies to the document owner or the Information Security Officer.

7. Review & Maintenance

This policy is reviewed:

  • At least annually, as part of the ISMS management review cycle.
  • When the documentation framework or tooling changes significantly.
  • When audit findings identify documentation control weaknesses.
  • When new regulatory requirements affect document retention or control procedures.

Sources

ISO 27001 Controls Covered

A.5.1 Policies for information security A.5.35 Independent review of information security A.5.36 Compliance with policies, rules and standards for information security A.5.37 Documented operating procedures

Frequently asked questions

How many levels does my document hierarchy need?

Four levels have proven effective: the Information Security Policy at the top, topic-specific policies below it (access control, cryptography, etc.), then management documents (risk register, audit programme, treatment plan), and operational records at the bottom (incident reports, training evidence, ticket logs). Our template maps exactly this structure.

Does top management really have to approve every policy?

The overarching information security policy: yes, ISO 27001 Clause 5.2 requires this explicitly. Topic-specific policies may be approved by the management level with appropriate authority and technical competency for the domain — for example the IT director for the IT operations policy. The key requirement is that the approver is documented and has the necessary competence.

How often must policies be reviewed?

At least annually. Additionally when there are significant changes to business strategy, the regulatory environment, technical infrastructure, or after security incidents that revealed documentation gaps. The template lists six specific triggers.

What do I do with obsolete documents?

Obsolete versions are marked as such but remain visible in the version archive. This is essential for the audit trail — auditors need to trace which version was in effect at a given point in time. Deletion is not an option as long as statutory retention periods apply.

Do I need a separate document for every operating procedure?

A 5.37 requires documented operating procedures for standardised, infrequent and risk-critical activities. That means: if multiple people perform a task and consistency matters, you need a documented procedure. A single operations handbook can bundle several procedures — as long as each one is clearly delineated, versioned and assigned to a responsible role.