A.5.1
Policies for information security
Organizational controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control establishes management direction and commitment to information security through documented policies applied consistently across the organization. It requires a top-level information security policy together with topic-specific policies (access control, cryptography, asset management, and so on), each approved by management, published and communicated to personnel and relevant external parties, and reviewed at planned intervals and when significant changes occur.
Key checkpoints
- Is a top-level information security policy established and approved by management, reflecting business objectives, legal/regulatory requirements, and the risk environment?
- Are topic-specific policies (access control, cryptography, asset management, incident response, and so on) defined to support the top-level policy?
- Are the policies published in a form accessible to personnel and relevant external parties, with acknowledgement confirmed (through pledges, training, and so on)?
- Is a policy owner assigned, and are policies reviewed at planned intervals and upon significant organizational, technical, or threat changes to keep them current?
- Are policy exceptions (exclusions, time-limited allowances) requested, approved, and recorded, with validity periods and review dates managed?
- Are the versions and distributed copies of policy documents controlled so that a superseded version is not still in use after a revision?
Implementation guidance
- Keep the top-level policy concise: management commitment, scope, information security objectives, the framework of roles and responsibilities, and the principle for action on violations.
- Arrange topic-specific policies in a clear hierarchy that does not conflict with the top-level policy, and state each policy's owner and review cycle.
- Maintain approval records (approver, approval date, version) and record change history on each revision.
- Deliver the policies at onboarding and at the start of contracts, and re-announce them on change to keep awareness current.
- Set a regular review cycle (for example, annually) and review on demand when triggers occur, such as reorganization, launch of new services, or a major incident.
- Record each policy exception together with its rationale, compensating control, approver, and validity period, and have it re-reviewed when that period expires.
Evidence
- Top-level information security policy approved by management (including version and approval date)
- List and documents of topic-specific policies/guidelines
- Records of policy publication/communication (intranet postings, training/pledge records)
- Policy review/revision history and review meeting minutes
- Policy exception requests and approvals, and an exception register including validity periods
- Version control register for policy documents, and records of withdrawing or retiring superseded versions
Nonconformity examples
- An information security policy exists as a document but there is no evidence of formal management approval.
- Only a top-level policy exists; topic-specific policies such as access control or cryptography are not defined, leaving no operational basis for practice.
- The policy was established but has not been reviewed or updated for years, so it no longer matches the current organization and systems.
- The policy is shared only with a specific department and is not communicated or published to personnel and external parties.
- A policy exception is granted verbally only, with no record of its rationale, approver, or validity period, so the exception status cannot be determined.
- A policy is revised but the superseded version remains on the intranet and in department shared folders, so both are used in practice.