Policies for information security

What the requirement asks

An overarching information security policy and a set of topic-specific policies are to be written, signed off by management, made available, brought to the attention of the staff and outside parties they concern, confirmed as received by those people, and revisited on a schedule and whenever something significant changes. Purpose: keep management's direction on information security fit, sufficient and working, in line with business, legal, regulatory and contractual needs. Guidance: top management approves the top-level policy, which states how the organization runs information security and draws on business strategy, laws and contracts, and present and expected risks and threats. It should cover what information security means for the organization, its objectives or how they are set, guiding principles, a commitment to meet applicable requirements and to keep improving the ISMS, which roles hold which responsibilities, and how exemptions and exceptions are handled; top management signs off any change to it. Beneath it sit topic-specific policies aimed at particular audiences or areas (for example access control, physical security, assets, information transfer, endpoint configuration, networks, incident management, backup, cryptography and keys, classification, technical vulnerabilities and secure development), consistent with the top policy and owned by people with the right authority and expertise. Reviews look for improvement and respond to shifts in strategy, technology, law and contracts, risks, the threat landscape and incident lessons, using management review and audit results, and check related policies for consistency. Policies should be understandable to their readers, acknowledged where appropriate, and screened for confidential content before being shared externally. The top policy is general and approved by top management; topic policies are detailed and approved at a suitable management level. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

The policy set is the first test of the system. The guidance expects one top-level policy, the topic policies it depends on and a route for exceptions. The evidence question is whether a reader can find the current version and the approval behind it.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep the top-level information security policy with top management approval, covering the definition, objectives or objective-setting framework, principles, commitments to requirements and continual improvement, role assignments and the exceptions procedure and one live sample together.

Evidence an assessor asks for

• Policy governanceThe top-level information security policy with top management approval, covering the definition, objectives or objective-setting framework, principles, commitments to requirements and continual improvement, role assignments and the exceptions procedure
• Policy governanceThe register of topic-specific policies with an owner, approving manager and version for each
• Policy governanceReview records showing the planned interval met and ad hoc reviews after changes in strategy, technology, regulation, risk, threats or incidents, with management review and audit results as inputs
• Policy governanceAcknowledgement records from personnel and relevant external parties that they understand and will comply
• Policy governanceChange log showing top management approval of every change to the top-level policy
• Policy governanceEvidence that externally distributed policy versions were checked for confidential content

The question an assessor will ask

An assessor will ask for the top-level information security policy with top management approval, covering the definition, objectives or objective-setting framework, principles, commitments to requirements and continual improvement, role assignments and the exceptions procedure, then trace it to the system it protects. For A.5.1 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Topic-specific policies referenced in the top policy were never written or have no named owner
• Reviews are calendar driven only and ignore significant incidents or regulatory change
• No procedure exists for handling exemptions and exceptions, so exceptions are granted informally
• Acknowledgement collected once at onboarding and never again after policy revisions

Before the next audit

Before the next audit, check one live sample for this gap: topic-specific policies referenced in the top policy were never written or have no named owner.