Information Security Policy Hierarchy

The three-tier model separates what must be done (policy) from how it must be done (standard) and from the steps taken to do it (procedure). This separation is deliberate. Senior executives can approve a policy without understanding the technical implementation; technical staff can update a standard when a configuration benchmark changes without requiring board approval; operational staff can follow a procedure without needing to understand the governance rationale. When all three are collapsed into a single document, any change requires re-approval at the highest level, the document becomes unmanageable in length, and version control fails.

A fourth document type, the guideline, sometimes appears below procedures. Guidelines are recommendations rather than mandates; staff may deviate from them without a formal exception. The distinction matters for auditors: a finding against a policy or standard is a compliance gap, but a finding against a guideline is an observation. Organisations that mix mandatory and advisory language in the same document create scope ambiguity that auditors will flag.

A policy document should state its purpose, scope, the roles it applies to, the key requirements, and the consequence of non-compliance. It should not contain system-specific configuration details, because those belong in standards. A policy that specifies, for example, that passwords must be at least 12 characters is already mixing tiers: the 12-character requirement is a standard, and it will need to be updated when the benchmark changes, triggering a board-level re-approval that should not be necessary for a configuration threshold.

The authoring workflow typically runs as follows. The CISO or security team drafts the policy, often starting from a framework template such as the ISO/IEC 27001 Annex A topic-specific policy list or the NIST SP 800-53 governance controls. A legal review confirms alignment with applicable law: GDPR Article 32 in the EU, the Digital Personal Data Protection Act 2023 in India, HIPAA Security Rule in the US, or sector-specific regulation such as PCI-DSS. The draft then goes to a review panel that includes IT, legal, HR, and the relevant business unit. After revisions, it is submitted to the approval authority. Once approved, the policy receives a version number, an effective date, and a scheduled review date, all recorded in the document header or a document register.

The approval authority for the overarching information security policy is typically the board or the CEO, because this document assigns organisation-wide accountability. Topic-specific policies, such as an acceptable use policy or a remote access policy, may be approved at the CISO level if the organisation's governance structure permits delegation. The approval record must be retained: auditors will ask for the signed approval or the meeting minutes that capture the approval decision.

Standards translate policy requirements into criteria that can be tested. A password policy might require that authentication controls protect access to organisational systems. The corresponding standard specifies: minimum password length 12 characters, must include uppercase, lowercase, digit, and special character, maximum age 90 days, no reuse of the last 12 passwords, account lockout after five failed attempts. Each criterion is measurable, and an auditor can verify compliance by inspecting the Active Directory group policy object, the cloud identity provider configuration, or the system configuration baseline.

Standards are authored by technical subject-matter experts and reviewed by the security team. They are often aligned to external benchmarks: CIS Benchmarks for specific systems, NIST SP 800-63 for digital identity, PCI-DSS Requirements for payment card systems, or vendor security hardening guides. When an external benchmark updates, the internal standard should be reviewed against the new version. This is a common gap found in audits: an organisation adopted CIS Level 1 in 2021 but has not reviewed its standard since the benchmark released a new version.

A procedure translates a standard requirement into a sequence of named steps that a specific role performs. It answers who does what, in what order, using which tools, and what they record as evidence. Procedures should be written in plain language that the target audience can follow without specialist knowledge beyond the role's normal training. Each step should be an action, not a concept.

For example, a standard requires that user accounts be disabled within four hours of termination notification. The procedure for the IT operations team would list: receive the HR termination notification; locate the user account in the identity management system; disable the account and record the time; revoke active sessions; notify the manager and HR that the action is complete; log the ticket number and completion timestamp in the termination register. Each step is an action, each step has an actor (IT operations), and the final step produces the evidence record that auditors will inspect.

Procedures are approved by the process owner, typically a department head or team lead. They do not require CISO or board approval unless they include a security decision. Procedures are updated more frequently than policies or standards: any change to the tools, systems, or workflow may trigger a revision. Version control is critical at this tier because outdated procedures can cause staff to follow a process that no longer matches the current system, producing a gap between documented and actual practice.

A policy that staff cannot find or have not read provides no governance control. Communication requirements are explicit in several frameworks: ISO/IEC 27001 clause 7.3 requires that relevant persons are aware of the information security policy; NIST SP 800-53 AT-2 requires security awareness training that covers security policies. The communication programme must reach all staff, including contractors and third parties who have access to organisational systems.

Common mechanisms include: mandatory annual policy acknowledgment requiring a signed or system-logged confirmation that the employee has read and agrees to comply; induction training for new joiners that covers the core policies before access to systems is granted; a central policy repository accessible to all staff, with search capability; and periodic refresher communications when a policy is updated. The acknowledgment record is the primary audit evidence for the communication control.

Auditors distinguish between distribution and awareness. Sending an email with a policy attachment satisfies distribution but not awareness. Awareness requires evidence that staff understood the key requirements, typically demonstrated through training completion records, quiz scores, or scenario-based acknowledgment. Organisations that rely on email distribution alone consistently receive audit findings on the awareness control.

An audit of the policy hierarchy tests three properties: currency (are documents up to date?), communication (have the right people read them?), and enforcement (do controls actually implement what the documents require?). Each property requires different evidence and different testing techniques.

For currency, the auditor inspects the document register or policy management system to confirm that each document shows a review date within the required interval, an approval signature or equivalent electronic record dated at or after the last review, and a version number consistent with the change history. Documents that have passed their review date without a recorded re-approval are stale; stale policies generate findings regardless of whether the content is technically adequate, because the governance process itself has failed.

For communication, the auditor requests the acknowledgment register and compares it to the current staff list, including contractors and third parties in scope. Any gap between the staff list and the acknowledgment register is a finding. The auditor may also select a sample of employees for interview, asking them to describe the core requirements of the acceptable use policy or the password standard to test whether the training produced awareness, not just a signature.

For enforcement, the auditor selects a sample of controls stated in the standards and tests them for operating effectiveness. If the password standard requires a 12-character minimum, the auditor inspects the relevant system configuration to confirm that the setting is applied. If the procedure requires accounts to be disabled within four hours of termination, the auditor samples recent terminations and compares the HR notification timestamp to the account disable timestamp in the system log. Where the standard is not reflected in the control configuration, or where the procedure was not followed, the auditor raises a finding against the relevant tier of the hierarchy.