Ask any experienced ISO 27001 auditor what they find most frequently in first-cycle certification audits, and the answer is usually some variation of the same thing: policies that were written to describe an ideal rather than govern reality. Generic templates with the organization's name at the top. Procedures that describe what should happen but bear no resemblance to what actually happens. Documentation that exists to satisfy auditors rather than to direct staff behavior.
This gap between documentation and reality is the single most common source of audit findings — and the most avoidable. Writing ISMS documentation that is both conforming and genuinely useful is not a harder task than writing documentation that looks right but does not function. It requires the same amount of effort, applied differently: to understanding the organization's actual processes, translating them into clear requirements, and building the approval and communication chains that make policies real rather than nominal.
This article covers the complete policy and procedure development discipline — from the fundamental distinction between what policies and procedures are for, through annotated templates for the IS Policy and supporting policies, to the document development workflow that ensures quality and the common mistakes that generate nonconformities.
Policy vs. Procedure: The Critical Distinction
Before writing a single word of ISMS documentation, the distinction between a policy and a procedure must be clear. These are different document types serving different purposes for different audiences. Mixing them up — producing policies that contain operational steps, or procedures that contain only principles — is one of the most common structural mistakes in first-cycle implementations.
| Dimension | Policy — what and why | Procedure — how |
| Purpose | States what the organization will do and why — the commitment and the standard | Explains how to do it — the step-by-step operational detail |
| Audience | All relevant staff — everyone who must understand the standard | Staff who perform the specific activity |
| Level of detail | High-level principles and requirements. No step-by-step instructions. | Specific steps, decision points, forms, and reference materials |
| Approval authority | CEO / executive sponsor for top-level policy; CISO for domain policies | Process owner / CISO |
| Review trigger | Annual review minimum; significant business change; regulatory update | When the process changes; when audit finds gaps; annually |
| Length | 2–6 pages for most domain policies. Top-level IS policy: 2–4 pages. | As long as needed for clarity. Typically 3–15 pages. |
| Example | Access Control Policy — states that all access must be role-based, reviewed quarterly, and revoked within 4 hours of departure | User Access Review Procedure — step-by-step process for conducting the quarterly access review including query steps, approval workflow, and evidence recording |
| ISO 27001 reference | Clause 5.2 (IS Policy); Annex A 5.1 (IS policies general) | Clause 7.5 (documented information); implied by operational control requirements throughout Annex A |
The hierarchy flows: policy establishes the requirement, procedure explains how to fulfill it. A policy that says 'access reviews shall be conducted quarterly' is complete and correct. A procedure then explains who runs the query, which systems are included, how the results are distributed to managers, how changes are actioned, and what evidence is retained. Staff need both — the policy to know the standard, the procedure to know how to meet it.
| THE GOVERNANCE TEST | A policy is governed correctly when: (1) Someone with authority signed it. (2) The people who must follow it have read it and acknowledged it. (3) It is reviewed when the context it governs changes. A procedure is governed correctly when: (1) The people who execute it wrote or contributed to it. (2) It accurately describes what actually happens. (3) It is updated when the process changes. Policies approved by people who don't follow them, and procedures that describe processes nobody actually uses, fail both tests. |
The Information Security Policy: An Annotated Template
The Information Security Policy is the most scrutinized document in an ISO 27001 certification audit. Auditors read it carefully during Stage 1 to assess whether the organization has genuinely internalized the requirements of Clause 5.2. A policy that satisfies auditors is not the same as a policy that governs behavior — but it is a necessary starting point. The template below covers every required element, with annotation explaining what makes each section conforming:
Document Header
Every controlled ISMS document should have a standardized header containing the following fields:
| Document field | Example content | Guidance note |
| Document title | Information Security Policy | Use a consistent naming convention across the ISMS document suite |
| Document ID | ISMS-GOV-POL-001 | Follow the document register naming convention. Tier-Domain-Type-Number. |
| Version | v2.0 | Major.Minor — v1.0 initial, v1.1 minor update, v2.0 major revision requiring re-approval |
| Status | Approved / Draft / Under Review / Superseded | Only 'Approved' documents should be in the active controlled register |
| Effective date | 15 January 2026 | Date top management formally approved this version |
| Review date | 15 January 2027 | Minimum annual review. Earlier if significant changes occur. |
| Document owner | Chief Information Security Officer | Role title, not individual name. Owner is accountable for document currency. |
| Approved by | Chief Executive Officer | Must be top management for IS Policy. CISO for supporting policies. Record name and title. |
| Scope | Applies to all employees, contractors, and third parties accessing [Organization Name] information systems within the ISMS scope. | Matches the ISMS scope statement. Be specific about who is covered. |
Policy Body — Annotated Content Template
The table below provides draft language for each required section of the Information Security Policy, with annotation explaining the ISO 27001 conformance rationale. This is not a finished document — it is a starting framework that must be customized with the organization's specific details, regulatory obligations, and operational context:
| Section | Draft language (adapt to your organization) | Annotation — what makes this section conforming |
| 1. Introduction | [Organization Name] relies on information assets to deliver its services. This policy establishes the framework for protecting the confidentiality, integrity, and availability of information assets within the scope of the Information Security Management System (ISMS). | One paragraph. States the purpose and establishes the policy's authority. Avoid generic language — reference the organization's specific services. |
| 2. Scope | This policy applies to all employees, contractors, consultants, and third parties who access [Organization Name]'s information systems and data within the ISMS scope, as defined in the ISMS Scope Statement [ISMS-GOV-DOC-001]. This policy covers all information assets processed, stored, or transmitted in connection with [core service description]. | Must match the ISMS scope statement exactly. Name specific exclusions if applicable. |
| 3. Regulatory and Standards Compliance | [Organization Name] operates under the following regulatory obligations relevant to information security: UU No. 27 Tahun 2022 (Perlindungan Data Pribadi / UU PDP); POJK No. 11/POJK.03/2022 on IT Risk Management [if applicable]; PBI No. 23/6/PBI/2021 on Payment System Security [if applicable]; ISO/IEC 27001:2022 as the framework for this ISMS. | Name specific regulations by number. Generic 'applicable laws and regulations' is insufficient. Update when new regulations come into force. |
| 4. Information Security Principles | [Organization Name] is committed to: Protecting the Confidentiality of customer, employee, and organizational information from unauthorized access or disclosure; Maintaining the Integrity of information to ensure it is accurate, complete, and unaltered; Ensuring the Availability of information systems to support business operations and meet service obligations; Managing information security risks in a systematic and documented manner through this ISMS. | The CIA triad stated explicitly. These four commitments connect to Clause 5.2's content requirements. |
| 5. Risk Appetite | [Organization Name] maintains a LOW risk appetite for risks involving customer personal data and financial transaction integrity. We maintain a MODERATE risk appetite for operational efficiency risks and internal process risks. Risk treatment decisions must align with this appetite. Risks scored HIGH (10–16) require documented management approval for acceptance. Risks scored CRITICAL (17–25) must be treated — acceptance is not permitted without executive sponsor approval. | This is one of the most important sections — and the most commonly omitted. State the risk appetite specifically. Connect it to the risk scoring methodology. This is what 'compatible with the strategic direction' requires. |
| 6. Roles and Responsibilities | The Board / Executive Management is accountable for the overall effectiveness of the ISMS and the approval of this policy. The CISO is responsible for managing the ISMS, maintaining this policy, and reporting ISMS performance to management. All staff are responsible for complying with this policy and reporting security incidents. Asset owners are accountable for protecting the information assets within their domain. Risk owners are accountable for approving risk treatment decisions for risks in their domain. | Brief role summary — detailed RACI lives in the roles and responsibilities document. Enough to establish accountability without duplicating Clause 5.3 documentation. |
| 7. Information Security Objectives | Information security objectives are established annually and reviewed at management review. Objectives are documented in the IS Objectives Register [ISMS-GOV-OBJ-001] and are consistent with this policy. Current objectives include [brief summary or reference to objectives register]. | Either list the current objectives or reference the objectives register. Clause 5.2 requires the policy to 'include IS objectives or provide a framework for setting them'. |
| 8. Consequences of Non-Compliance | Non-compliance with this policy may result in disciplinary action up to and including termination of employment or contract. Violations that constitute criminal offences under Indonesian law — including UU PDP, UU ITE, or other applicable legislation — will be reported to appropriate authorities. Third parties who breach this policy may have their contracts terminated. | Must be present. Proportionate but clear. The disciplinary mechanism is what gives the policy teeth. |
| 9. Continual Improvement | [Organization Name] is committed to the continual improvement of this ISMS. The ISMS will be reviewed at planned intervals through management reviews, internal audits, and corrective action processes. This policy will be reviewed annually and updated to reflect changes in the organizational context, threat environment, and regulatory requirements. | Satisfies Clause 5.2's requirement for a commitment to continual improvement. References the management system mechanisms that drive improvement. |
| 10. Policy Review | This policy is reviewed annually by the CISO and approved by the CEO. Reviews are triggered immediately by significant changes to organizational context, regulatory requirements, or the ISMS scope. The document owner is responsible for initiating reviews and obtaining approval before the next version is communicated to staff. | Review clause completes the document control loop. Sets clear responsibility and trigger conditions. |
| The risk appetite section (Section 5) is the most frequently missing element in first-cycle IS policies. Many organizations omit it because it requires a genuine management conversation about how much risk the organization is willing to accept. This conversation is uncomfortable — it forces executives to make explicit commitments rather than speaking in generalities about 'protecting all information'. But it is exactly this conversation that Clause 5.2's requirement to be 'compatible with the strategic direction' is designed to produce. Do not omit it. |
Supporting Policy Suite: Required Sections
The supporting policy suite operationalizes the top-level IS Policy for specific security domains. Each supporting policy must cover certain mandatory sections to be considered complete. The table below maps the required sections for six core supporting policies, along with their primary Annex A control coverage:
| Policy | Required sections | Annex A controls |
| Access Control Policy |
| A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3, A.8.5 |
| Incident Management Policy |
| A.5.24, A.5.25, A.5.26, A.5.27, A.5.28 |
| Data Classification Policy |
| A.5.12, A.5.13, A.5.14 |
| Supplier Security Policy |
| A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 |
| Cryptography Policy |
| A.8.24 |
| Business Continuity & DR Policy |
| A.5.29, A.5.30, A.8.14 |
| Indonesian-specific content for Incident Management Policy: The incident management policy must explicitly address UU PDP's 14-day breach notification obligation to KOMINFO. The standard international template language ('notify relevant authorities within a reasonable timeframe') is not sufficient for Indonesian organizations. The policy must name KOMINFO as the notification authority, state the 14-day calendar day trigger from discovery (not confirmation), and describe the consequence of notification failure under UU PDP Article 57. OJK-regulated entities must also address OJK notification timelines separately. |
Writing Effective Procedures: A Worked Example
Procedures must be specific enough to be followed without interpretation. The best test of a good procedure is to hand it to a new employee who has never performed the task and observe whether they can complete it correctly without asking questions. If they need to ask questions, the procedure has gaps.
The template below shows a complete access review procedure at the level of detail required for ISO 27001 certification. This is the type of procedure document that satisfies both auditors (by demonstrating that the policy's quarterly review requirement is operationalized) and staff (by telling them exactly what to do):
| Section | Content (adapt to your organization's systems and processes) |
| 1. Purpose | This procedure defines the process for conducting quarterly information access reviews to ensure that user access rights remain appropriate and that stale or excessive access is identified and removed. This procedure operationalizes the Access Control Policy [ISMS-SEC-POL-002] requirement for quarterly access reviews. |
| 2. Scope | This procedure applies to all systems within the ISMS scope: production application servers, customer database, cloud infrastructure (AWS), internal business systems accessible to production environment staff. Excludes: development workstations, test environments with no production data access. |
| 3. Roles and Responsibilities | Access Review Owner: Head of IT — initiates and oversees each review cycle. System Administrators: Run access queries and compile access reports. Business Unit Managers: Review and confirm appropriateness of access for their direct reports. CISO: Receives completed review report and retains as ISMS evidence. |
| 4. Review Trigger | Quarterly review: scheduled within the first 10 business days of Q1/Q2/Q3/Q4. Emergency review: triggered within 5 business days of (a) staff departure, (b) significant role change, (c) security incident involving unauthorized access, or (d) major system change. |
| 5. Procedure Steps | Step 1: Access Review Owner initiates review and notifies all System Administrators (Day 1). Step 2: System Administrators generate access reports for all in-scope systems — export user lists with access rights and last login date (Days 1–3). Step 3: Distribute reports to Business Unit Managers for their direct reports. Deadline: 5 business days for review completion (Days 3–8). Step 4: Business Unit Managers mark each user as 'Confirm', 'Modify', or 'Revoke'. Provide justification for any access retained that appears inconsistent with current role. Step 5: System Administrators action all 'Modify' and 'Revoke' decisions within 2 business days of receiving completed review (Days 8–10). Step 6: Access Review Owner compiles completion report: total users reviewed, changes made, stale accounts deactivated, completion date. Step 7: Completed report submitted to CISO for retention as ISMS evidence. |
| 6. Evidence to Retain | Access reports exported from systems (showing users, access rights, last login). Completed review forms with Business Unit Manager sign-off. Summary of access changes made. Access Review Completion Report (template: ISMS-SEC-TPL-007). Retention period: 3 years per document retention schedule. |
| 7. Exceptions | Access that cannot be reviewed within the standard timeline due to staff absence or system unavailability must be documented with the reason and a revised completion date. Exceptions requiring more than 5 additional business days must be approved by the CISO. All exceptions are recorded in the access review log. |
| 8. Non-Compliance | Failure to complete the access review within 10 business days of initiation without an approved exception constitutes a process non-compliance and must be logged as a corrective action item. Repeated non-compliance is escalated to the ISMS Steering Committee. |
| Procedure format note: The access review procedure above is deliberately detailed at Steps 4 and 5 — the review execution steps. This level of specificity is what distinguishes a procedure that governs from one that describes. 'Business Unit Managers review access and confirm appropriate' is description. 'Business Unit Managers mark each user as Confirm, Modify, or Revoke and provide justification for access retained that appears inconsistent with current role, using the access review form ISMS-SEC-FRM-003, returning within 5 business days' is a procedure. The difference matters both operationally and in audit. |
The Document Development Workflow
Every ISMS document should pass through a defined development and approval workflow. Ad hoc documentation — written quickly, approved informally, distributed without tracking — produces the version control problems, approval gaps, and communication failures that generate audit findings. The 8-step workflow below applies to every new or significantly revised ISMS document:
| # | Phase | Responsible | Activity | Output |
| 01 | Draft | Document owner (ISMS Lead or process owner) | Write the policy or procedure using the standard template. Reference applicable Annex A controls and regulatory requirements. Include all required sections. Use plain language accessible to the target audience. | Draft document in document management system. Status: DRAFT. |
| 02 | SME Review | Subject matter expert (IT lead, legal, HR as relevant) | Review for technical accuracy, completeness, and operational feasibility. Can staff actually follow this procedure? Are the technical requirements achievable with current infrastructure? | Reviewed draft with tracked changes or written review comments. Target: 5 business days. |
| 03 | Stakeholder Review | Affected business unit managers and process owners | Review for operational impact. Does this policy create unreasonable burden? Are exceptions anticipated that should be pre-addressed? Are the timelines realistic? | Stakeholder comments addressed or documented as deliberate policy decisions. Target: 5 business days. |
| 04 | Legal / Compliance Review | Legal Counsel / Compliance Manager | Review for regulatory compliance. Does the policy accurately reflect UU PDP obligations? Are the breach notification triggers correct? Do supplier requirements match contractual obligations? | Legal sign-off on regulatory compliance. Critical for IS Policy, Incident Management Policy, Data Classification Policy. Target: 5 business days. |
| 05 | Approval | CEO (IS Policy); CISO (supporting policies); Process owner (procedures) | Formal approval. Version number incremented. Effective date set. Approval signature (wet or electronic) recorded in document register. | Approved document. Status changed from DRAFT to APPROVED. Document register updated. Target: 2 business days. |
| 06 | Publication | ISMS Manager | Publish to staff-accessible location (ISMS intranet, GRC platform). Send notification email to all affected staff. For IS Policy: send directly to all staff. For supporting policies: send to relevant teams. | Publication record (email send log, intranet publish date). Notification records. Status: ACTIVE. |
| 07 | Acknowledgment | All affected staff | Staff read and acknowledge the policy. Tracked in LMS or document management system. Follow up with non-responders within 5 business days. Target: 100% completion within 15 business days. | Policy acknowledgment records by staff member and document version. Retained as ISMS evidence. |
| 08 | Review | Document owner | Annual review triggered by calendar entry or earlier by change events (regulatory update, business change, audit finding). Update content if needed. If no changes, document confirmation of review and extend review date. | Updated document (new version) or review confirmation note in document register. New effective date and review date set. |
The total elapsed time for a new supporting policy through this workflow is typically 15–20 business days — assuming no major disagreements emerge during stakeholder review. Planning the policy development schedule should account for this timeline. Starting policy development too late in Phase 3 creates a crunch at the Phase 4 entry point where controls need to be implemented against approved policies.
| Bitlion document management: Bitlion's platform includes a document management module that tracks every policy and procedure through the development and approval workflow — draft status, reviewer assignments, approval routing, publication confirmation, and staff acknowledgment tracking. The document register is maintained automatically, version history is retained, and review date reminders trigger 30 days before each policy's scheduled review. Evidence of document control health is available in real time for audit preparation. |
Common Policy and Procedure Mistakes
The table below maps the seven most common policy and procedure failures found in certification audits — with their audit impact, the explanation for why they occur, and the fix:
| Common mistake | Audit impact | Why it happens / Impact detail | How to fix it |
| Generic template not customized | Nonconformity likely | Immediate audit finding. Policy contains language irrelevant to the organization (references wrong industry, wrong regulations, wrong systems). Auditors identify templates within minutes of reading. | Every section must be customized. Names of specific systems, specific regulations by article number, specific RTO/RPO values. If a section doesn't apply, delete it or explain why it's not applicable. |
| Policy approved by CISO instead of CEO | Minor NC likely | Clause 5.2 nonconformity. The Information Security Policy must demonstrate top management leadership and commitment. CISO approval signals the ISMS is an IT program, not a management system. | IS Policy signed by CEO. Supporting policies may be signed by CISO. Document the approval clearly — date, name, title, and role. |
| No consequence statement | Minor NC likely | Policy appears aspirational rather than governing. Auditors view policies without consequence statements as indicating weak management system culture. | Add a clear, proportionate consequence section. Reference UU PDP criminal provisions for data breach concealment. Reference employment law for staff non-compliance. |
| Policy references systems that no longer exist | Observation likely | Signals that policies are not being maintained. Minor nonconformity — but multiple occurrences indicate systemic document control weakness. | Annual policy review should include checking system references. When systems are decommissioned, update all policies that reference them within 30 days. |
| Procedure not linked to governing policy | Observation likely | Auditors cannot trace the governance hierarchy. Procedures floating without policy connection appear as orphaned documents with no clear authority. | Every procedure must reference its governing policy in Section 1 (Purpose) or Section 2 (Scope). Add cross-reference table to document register. |
| Policy reviewed but not re-approved after change | Observation likely | A changed policy without updated approval is a new document masquerading as an approved one. Version control and approval signature must reflect the current version. | Every content change — even minor — requires incrementing the version number and obtaining approval. Document control procedure must mandate this. |
| Staff not notified of updated policy | Observation likely | Clause 5.2 requires the policy to be communicated. If staff have not been notified of a significant policy update, the communication requirement is not met for the new version. | Policy update triggers re-communication and re-acknowledgment. LMS enrollment updated to reflect new version. Previous completion records not sufficient for updated policy. |
The overwhelming majority of these mistakes share a common root cause: documentation was produced to satisfy a requirement rather than to govern behavior. The fix in every case is the same — before finalizing any policy or procedure, ask whether a staff member who reads it and nothing else would know what is expected of them and what happens if they do not comply. If the answer is no, the document needs more work.
The Minimum Document Set for Certification
Organizations frequently ask what the absolute minimum ISMS documentation is for certification. The honest answer is that minimum depends on scope — a broader scope requires more documentation. But for a focused-scope first-cycle implementation, the following represents the minimum viable document set:
- Governance: Information Security Policy (Clause 5.2 — explicit requirement)
- Governance: ISMS Scope Statement (Clause 4.3 — explicit requirement)
- Governance: IS Objectives Register (Clause 6.2 — explicit requirement)
- Risk: Risk Assessment Methodology (supports Clause 6.1.2 consistency requirement)
- Risk: Risk Register / Risk Assessment Results (Clause 6.1.2 — explicit requirement)
- Risk: Statement of Applicability (Clause 6.1.3 — explicit requirement)
- Risk: Risk Treatment Plan (Clause 6.1.3 — explicit requirement)
- Policy: Access Control Policy + Access Review Procedure
- Policy: Incident Management Policy + Incident Response Procedure
- Policy: Data Classification Policy
- Policy: Acceptable Use Policy
- Policy: Supplier Security Policy
- Policy: Cryptography Policy
- Policy: Business Continuity & DR Policy
- People: Competence records for ISMS roles (Clause 7.2 — explicit requirement)
- People: Awareness training records (Clause 7.3 — explicit requirement)
- Audit: Internal audit program and reports (Clause 9.2 — explicit requirement)
- Governance: Management review records (Clause 9.3 — explicit requirement)
- Improvement: Nonconformity and corrective action records (Clause 10.2 — explicit requirement)
| Minimum is a starting point, not an objective. The documents above represent what is needed to pass a first-cycle certification audit for a focused scope. A mature ISMS adds more procedures, more specialized policies (secure development, physical security, data retention), and more supporting documentation as the scope expands and the organization's needs develop. The document suite should grow with the ISMS. |
Documentation as Evidence of a Functioning ISMS
The ultimate test of ISMS documentation is not whether it satisfies auditors during a Stage 1 document review — it is whether staff understand their obligations, follow the procedures, and produce evidence that the system is actually operating. Documentation that exists but is not understood, not followed, and not evidenced in practice is worse than a liability: it creates a gap between what the ISMS claims and what it does, which is precisely what sophisticated auditors and regulators are trained to identify.
The organizations that get the most value from their ISMS documentation are those that treat policy and procedure writing as a communication task — not a compliance task. They write for the audience (staff who need to know what to do) rather than for the auditor (who needs to see that requirements are met). In doing so, they produce documentation that satisfies auditors because it genuinely governs behavior, rather than documentation that describes governance without producing it.