The gap assessment in Article 3.2 told you what you have and what is missing. Phase 3 is where you build what is missing — the policies, the governance model, the document architecture, the risk management infrastructure that will form the backbone of the ISMS. Building it right means building it as a coherent system, not as a collection of disconnected documents.
This is where many first-cycle implementations go wrong. The project team builds documents to fill gaps found in the assessment — a policy for each clause, a procedure for each control domain — without designing the architecture that connects them. The result is an ISMS that looks complete on a document register but does not function as a management system. Auditors identify this pattern through inconsistencies between documents, missing linkages between policies and procedures, and the inability of staff to explain how the documents connect to their work.
This article covers the framework architecture — what the ISMS structure should look like and how its components relate to each other — then works through the policy suite, document control system, and governance model that make the structure operational.
The ISMS Framework Architecture
An ISMS framework has five distinct layers. Each layer depends on the layers above it and feeds the layers below it. Understanding this hierarchy is essential for sequencing the build work in the right order — governance foundations first, evidence collection last.
| Governance Layer |
|
| Risk Management Layer |
|
| Policy & Procedure Layer |
|
| Control Evidence Layer |
|
| Monitoring & Improvement Layer |
|
The sequencing matters: you cannot write a meaningful access control policy before you have defined the scope (Layer 1). You cannot complete the SoA before the risk assessment is done (Layer 2). You cannot collect meaningful control evidence before the policies and procedures defining how controls operate are approved (Layer 3). Each layer provides the context that the layers below it require.
| ARCHITECTURE PRINCIPLE | An ISMS framework document should be traceable. A reader should be able to pick up any document and find its way to the risk it addresses (via the risk register), the clause it satisfies (via the clause reference), and the evidence that proves it is operating (via the evidence register). If any of those connections are missing, the document is floating — it exists but is not part of the management system. |
The Policy Hierarchy: Governance to Operational
Policies are the most visible component of an ISMS framework, and the most frequently criticized. Too many organizations produce policy documents that are either generic templates imported from the internet (and therefore not specific to the organization's context, scope, or regulatory environment) or exhaustive technical standards that nobody reads (and therefore not serving their governance purpose).
A well-designed policy hierarchy has three levels. The top-level governance policy (the Information Security Policy) states the organization's commitment, risk appetite, and framework for information security. Supporting policies cover each security domain in sufficient depth for process owners to understand their obligations. Procedures operationalize each supporting policy, providing step-by-step guidance for specific activities.
The table below maps the complete policy suite for an ISO 27001:2022 implementation, including the regulatory basis, key content requirements, primary Annex A coverage, and recommended build timeline:
| Policy document | Basis | Purpose and key content | Primary Annex A controls | Build timeline |
| Information Security Policy | Explicit (Clause 5.2) | Top-level governance document. States the organization's commitment to information security, its risk appetite, regulatory obligations, and framework for objectives. | All applicable controls — this is the governing document. | Week 2–4 (Phase 1 output) |
| Access Control Policy | Required by Annex A 5.15 | Defines how access to information and systems is granted, reviewed, revoked, and monitored. Covers user access, privileged access, remote access, and third-party access. | A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3, A.8.5 | Phase 3, Week 1–3 |
| Incident Management Policy | Required by Annex A 5.24–5.28 | Defines how security incidents are identified, reported, classified, responded to, and reviewed. Must explicitly cover UU PDP 14-day notification obligation and OJK/BI reporting requirements. | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28 | Phase 3, Week 1–3 |
| Supplier Security Policy | Required by Annex A 5.19–5.23 | Defines security requirements for supplier relationships — due diligence, contractual obligations, monitoring, and off-boarding. Covers cloud providers, SaaS, payment processors, and development outsourcing. | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 | Phase 3, Week 2–4 |
| Cryptography Policy | Required by Annex A 8.24 | Defines which cryptographic standards are approved, key management requirements, and the use of encryption for data at rest and in transit. Must reference current Indonesian regulatory requirements on encryption. | A.8.24 | Phase 3, Week 2–4 |
| Data Classification Policy | Required by Annex A 5.12–5.14 | Defines how information assets are classified (e.g. Public, Internal, Confidential, Restricted), labelled, and handled according to their sensitivity. Foundation for UU PDP personal data handling requirements. | A.5.12, A.5.13, A.5.14 | Phase 3, Week 1–3 |
| Asset Management Policy | Required by Annex A 5.9–5.10 | Defines how information assets are inventoried, owned, and protected throughout their lifecycle. Covers hardware, software, data, services, and people as asset categories. | A.5.9, A.5.10, A.5.11 | Phase 3, Week 2–4 |
| Business Continuity & DR Policy | Required by Annex A 5.29–5.30, 8.14 | Defines how the organization maintains information security during disruption. Must address ICT readiness for business continuity (new Annex A 8.14 control in 2022 revision). | A.5.29, A.5.30, A.8.14 | Phase 3, Week 3–5 |
| Acceptable Use Policy | Required by Annex A 5.10 | Defines permitted and prohibited use of information systems and assets. Covers email, internet, social media, removable media, and personal device use (BYOD). | A.5.10, A.6.2, A.8.1 | Phase 3, Week 1–2 (quick win — short policy) |
| Physical Security Policy | Required by Annex A 7.1–7.14 | Defines controls for securing physical environments, equipment, and facilities. May be minimal for fully remote organizations but must address home office security and equipment disposal. | A.7.1 through A.7.14 | Phase 3, Week 4–6 (scope-dependent) |
Policy Quality: What Makes a Policy Audit-Ready
Every policy in the ISMS suite should satisfy seven quality criteria before it is approved. These criteria distinguish policies that pass auditor scrutiny from those that generate observations or nonconformities:
| Quality criterion | What good looks like | What poor looks like (audit risk) |
| Scope and applicability | States explicitly who the policy applies to and what systems/processes it covers. The scope matches the ISMS scope statement. | Scope is undefined or so broad ('all information') that it is meaningless. |
| Ownership and approval | Named owner (role, not individual). Signed/approved by appropriate authority (CEO for top-level policy; CISO for supporting policies). Dated and version-controlled. | No named owner. No approval signature. Undated. No version number. |
| Regulatory alignment | Explicitly references applicable Indonesian regulations (UU PDP, POJK, PBI) and international standards (ISO 27001) where relevant. Not generic. | No regulatory references. Could apply to any organization in any country. |
| Operational clarity | Staff reading the policy can understand what they are required to do. Obligations are clear, specific, and actionable. | Policy is entirely aspirational ('we will protect all information') with no specific requirements. |
| Consequence statement | States what happens if the policy is not followed — disciplinary action, contract termination, regulatory reporting. Proportionate to severity. | No consequences stated. Staff have no understanding of the seriousness of non-compliance. |
| Review schedule | States when the policy will be reviewed (minimum annually). Review date is tracked in the document control register. | No review date. Policy may be years old without being flagged for update. |
| Connection to procedures | References supporting procedures that operationalize the policy (e.g. 'See Access Review Procedure for access review process'). Procedures exist and are current. | Standalone document with no linked procedures. Policy says 'conduct access reviews' but no procedure explains how. |
| The template trap: ISO 27001 policy templates are widely available online, and many implementations use them as starting points. This is acceptable if the template is substantively customized for the organization's context, regulatory environment, and operational reality. A policy that was downloaded from a compliance website, had the organization's name inserted at the top, and was approved without review is not a conforming policy — it is a document that exists but does not govern. Auditors distinguish between adapted templates and genuine organizational policies very quickly. |
Document Control: The System Behind the Documents
ISO 27001 Clause 7.5 requires all documented information to be controlled — identified, reviewed and approved, available when needed, protected from unauthorized modification, distributed appropriately, retained for the required period, and disposed of when obsolete. These are not just administrative requirements. They are what distinguishes a 'document that exists' from 'documented information that the organization relies on'.
The most practical approach to ISMS document control is a tiered structure that applies proportionate controls to different categories of document. More sensitive or higher-authority documents get more rigorous controls; operational records get lighter controls focused on retention and accessibility rather than approval chains:
| Document tier | Examples | Control requirement | Retention rule |
| Tier 1 — Governance Documents | ISMS Scope Statement, Information Security Policy, IS Objectives Register, Risk Appetite Statement | CEO or Board approval. Annual review minimum. Published to all staff. | Retain all versions. Active version in controlled document register. Superseded versions archived. |
| Tier 2 — Supporting Policies | Access Control Policy, Incident Management Policy, Data Classification Policy, Supplier Security Policy, and all other domain policies | CISO / ISMS Manager approval. Annual review minimum. Published to relevant staff. | Retain current version plus 2 previous versions. Review date tracked in document register. |
| Tier 3 — Procedures & Work Instructions | Access Review Procedure, Incident Response Procedure, Supplier Onboarding Procedure, Patch Management Procedure, Secure Coding Guidelines | CISO / Process Owner approval. Review triggered by policy change, process change, or audit finding. | Current version retained. Superseded versions archived with effective date and reason for change. |
| Tier 4 — Records & Evidence | Risk register, SoA, audit reports, training records, access review outputs, management review minutes, corrective action records | Retention schedule defined per record type. Access controlled to appropriate ISMS roles. | Retention periods: audit records 5 years minimum; training records 3 years; risk register entries for full certification cycle + 2 years. Defined in retention schedule. |
| Tier 5 — External Documents | ISO 27001:2022 standard, ISO 27002:2022, regulatory circulars (POJK, PBI, BSSN), UU PDP text, certification body guidelines | Maintained as reference copies. Version currency checked against official sources annually. | Retain current version. Previous versions retained if referenced in historical ISMS decisions. |
Practical Document Control Implementation
Document control does not require a sophisticated document management system. For most SME and mid-market implementations, a well-structured SharePoint library, a Confluence space, or the document management module within a GRC platform provides sufficient capability. What matters is not the tool but the discipline: every controlled document has a unique identifier, a version number, an approval date, and a review date. Superseded versions are archived, not deleted. The current version is the only one available to staff at the point of use.
The document register — a simple inventory of all controlled ISMS documents with their current version, approval date, review date, and owner — is the navigation tool for the ISMS library. It should be updated every time a document is created, revised, or retired. Auditors typically ask to see the document register early in a Stage 1 audit; a register that is incomplete or does not match the actual documents available signals weak document control.
| Document naming convention: A consistent naming convention prevents the document chaos that affects many implementations. A simple convention: [Category]-[Domain]-[Type]-[Number] — for example: ISMS-SEC-POL-001 (ISMS category, Security domain, Policy type, first in series). Version numbers follow a simple major.minor scheme: v1.0 (initial approved), v1.1 (minor update), v2.0 (major revision requiring re-approval). All documents include these elements in the header or footer. |
The Governance Model
A governance model is the system of meetings, reviews, decision processes, and accountability structures through which the ISMS is directed and controlled. Without a governance model, the ISMS has no operational rhythm — no regular cycle that keeps the management system alive between audits.
ISO 27001 requires several governance activities explicitly: management review (Clause 9.3), internal audit (Clause 9.2), monitoring and measurement (Clause 9.1), and corrective action management (Clause 10.2). The governance model defines when these activities occur, who leads them, who participates, and what outputs they produce. The table below maps the governance bodies needed for a functioning ISMS:
| Governance body | Frequency | Role in the ISMS |
| Board / Executive Management | Annual (at minimum) | Approve IS policy. Set risk appetite. Receive management review outputs. Allocate ISMS resources. Be accountable for ISMS effectiveness. |
| ISMS Steering Committee | Monthly during implementation; quarterly ongoing | Oversee ISMS program progress. Make resource allocation decisions. Review risk register status. Receive internal audit summaries. Direct improvement priorities. |
| Management Review (formal) | Annual minimum (quarterly recommended) | Structured review per Clause 9.3.2 agenda. Review all 8 required inputs. Produce documented decisions on improvement, changes, and resources. Chaired by CEO / executive sponsor. |
| ISMS Working Group | Bi-weekly during implementation; monthly ongoing | ISMS Manager + IT + Legal + BU reps. Tactical ISMS management. Risk register updates, policy reviews, corrective action progress, audit preparation. |
| Risk Owner Reviews | At risk assessment cycle and on significant change | Business unit managers review risks in their domain. Approve treatment decisions. Accept residual risks. Confirm risk register accuracy. |
| Internal Audit Program | Annual program; individual audits per schedule | Independent assessment of ISMS conformance. Produces findings, nonconformities, and observations. Reports to ISMS Manager and top management. |
The governance model should be documented — not as an elaborate governance charter, but as a simple calendar of recurring activities with defined agendas, participants, and outputs. The first management review, the internal audit schedule, and the ISMS steering committee calendar should all be established before Phase 3 ends. These calendar commitments are one of the most reliable predictors of whether the ISMS will still be functioning twelve months after certification.
| Governance calendar as a certification accelerator: Many certification bodies assess the governance health of an ISMS during Stage 1 by asking for evidence that the governance structures are operational — not just documented. Organizations that can show a steering committee calendar with past meeting minutes, a management review scheduled and confirmed, and an internal audit program running are significantly better positioned for a clean Stage 1 outcome than organizations that have the same structures defined on paper but not yet operational. |
Connecting the Framework: Integration Map
One of the most common ISMS framework weaknesses is disconnection — documents that exist in isolation rather than as part of a coherent system. Auditors test for this by asking questions like: 'Show me how the access control policy connects to the risk assessment' or 'Which risk drove the decision to implement MFA?'. Organizations that can trace these connections demonstrate a genuine management system. Those that cannot demonstrate they have a document collection.
The integration map below shows the key dependency relationships between ISMS framework components — how each element feeds the elements that depend on it:
| Framework element | Relationship | Feeds into |
| ISMS Scope Statement | defines boundary for | Risk Assessment |
| Context Analysis (4.1) | informs threats/issues in | Risk Assessment |
| Interested Parties Register (4.2) | defines requirements for | IS Policy + Objectives |
| Risk Assessment Results | drives control selection in | Statement of Applicability |
| SoA | determines policy topics in | Supporting Policy Suite |
| Risk Treatment Plan | creates implementation tasks in | Phase 4 Control Implementation |
| IS Policy | sets commitment context for | IS Objectives (6.2) |
| IS Objectives | provides targets for | ISMS KPI Dashboard (9.1) |
| All above documents | are the evidence base for | Internal Audit (9.2) + Management Review (9.3) |
Building these connections deliberately during Phase 3 — through cross-references in documents, clause annotations in the risk register, and traceability notes in the SoA — produces an ISMS that tells a coherent story to auditors rather than presenting a collection of independently produced artifacts.
The Phase 3 Build Checklist
The checklist below provides a week-by-week framework for Phase 3 framework construction. Activities are sequenced by dependency — governance foundations first, then risk infrastructure, then policy suite, then procedures, then governance mechanics. Each item represents a distinct deliverable that should be completed, reviewed, approved, and entered into the document register before the next phase's dependent activities begin:
| Week 1–2: Governance foundation |
☐ ISMS scope statement finalized and approved ☐ Information security policy drafted and submitted for CEO review ☐ Risk appetite statement drafted for executive discussion ☐ Document control procedure established ☐ Document register created with naming convention and version control ☐ GRC platform configured with ISMS document structure |
| Week 3–5: Risk management infrastructure |
☐ Risk assessment methodology documented and approved ☐ Asset inventory drafted for in-scope services and systems ☐ Risk register template configured in GRC platform ☐ Risk owner briefing conducted — all business unit managers briefed on their role ☐ Risk acceptance criteria agreed with executive sponsor ☐ IS objectives framework drafted (objectives to be set after risk assessment) |
| Week 6–10: Policy suite |
☐ Access Control Policy drafted and approved ☐ Incident Management Policy drafted — UU PDP notification obligation included ☐ Data Classification Policy drafted and approved ☐ Acceptable Use Policy drafted and approved ☐ Supplier Security Policy drafted — supplier register initiated ☐ Cryptography Policy drafted and approved ☐ Asset Management Policy drafted and approved ☐ Physical Security Policy drafted (if physical locations in scope) ☐ Business Continuity / DR Policy drafted and approved |
| Week 11–14: Procedure development |
☐ Access Review Procedure documented ☐ User Provisioning and De-provisioning Procedure documented ☐ Incident Response Procedure documented — escalation matrix completed ☐ Supplier Onboarding Security Procedure documented ☐ Vulnerability Management Procedure documented ☐ Patch Management Procedure documented ☐ Change Management Procedure — security gate added to existing process |
| Week 15–18: Governance mechanics |
☐ Management review agenda template created ☐ Internal audit program designed — schedule, audit universe, auditor assignments ☐ ISMS KPI dashboard configured in GRC platform ☐ Corrective action register template established ☐ Improvement register created ☐ Communication plan documented — who receives what, when, how |
| Bitlion GRC platform in Phase 3: Bitlion's platform provides the infrastructure for every Phase 3 deliverable — document register, risk register, SoA, policy templates with clause mapping, and governance activity tracking. Organizations that configure Bitlion early in Phase 3 find that document control, evidence collection, and audit preparation are substantially less effort in Phases 4 and 5 because the platform keeps everything connected, versioned, and audit-ready by design. |
Common Framework Build Mistakes
Building policies before the risk assessment
The risk assessment drives control selection (and therefore policy content). Organizations that build the full policy suite in Phase 3 before the risk assessment is complete in Phase 3 often have to revise policies when the risk assessment reveals controls that the policies do not cover or controls that the policies mandate but the organization has decided are not applicable. The correct sequence is: risk assessment first, then SoA, then policy suite based on applicable controls.
Creating documents for every conceivable scenario
Document inflation is a real problem. Some organizations produce 40+ policy documents, 60+ procedures, and dozens of templates — far more than is needed or maintainable. Every document created is a maintenance commitment. If the organization cannot keep all documents current and accurate, the ISMS will have documented information that conflicts with actual practice — which is worse from an audit perspective than having no documentation at all.
Approving policies without executive review
The Information Security Policy must be approved by top management — the CEO or equivalent. Supporting policies should be approved by the CISO. Procedures can be approved by process owners. When ISMS policies are approved by the IT Manager or by the ISMS Lead without executive sponsorship, the governance authority of the policy is undermined — and Clause 5.2's leadership requirement is not met.
| The framework completeness test: Before moving from Phase 3 to Phase 4, the ISMS framework should pass a completeness test: (1) Every applicable Annex A control domain has at least one policy addressing it. (2) Every policy has at least one procedure that operationalizes its key obligations. (3) Every document is controlled — versioned, approved, dated, and in the document register. (4) The governance calendar is confirmed — management review date set, internal audit program scheduled. If any of these conditions are not met, Phase 4 control implementation will produce evidence that cannot be connected to a governing policy, which creates nonconformities in the Stage 2 audit. |
The Framework as a Living System
The framework built in Phase 3 is not a finished product — it is the starting version of a management system that will evolve with every risk assessment cycle, every audit finding, every regulatory change, and every organizational transformation. The most durable ISMS frameworks are designed with this evolution in mind: document structures that can absorb new policies without becoming incoherent, governance models that scale as the organization grows, and risk management infrastructure that can accommodate scope expansion.
Organizations that treat the Phase 3 framework build as a one-time deliverable — complete it for certification and preserve it unchanged — consistently find that their ISMS becomes less accurate over time, generates more nonconformities in subsequent audits, and requires expensive reconstruction at the three-year recertification cycle. The organizations that treat it as the living foundation of an ongoing management program find that each successive cycle builds on a stronger, more accurate base.
Build it right. Then keep building it.