CSG study materials
CSG study resources

CSG: Security Policies, Standards and Procedures

CSG · Work through your exam, one topic at a time.

All guide sections

Security Policies, Standards and Procedures

This domain covers the documented layer of the security programme: how intent becomes mandatory requirements, then repeatable steps. The CSG exam tests the document hierarchy, the lifecycle from drafting to retirement, exception handling, and why poorly written or unapproved documents fail audits.

The hierarchy and what belongs at each level

  • Policy states management intent and mandatory direction - why and what. It is short, approved at executive level, and avoids technical detail. Example: "Information must be protected according to its classification."
  • Standard defines specific, mandatory requirements that satisfy the policy. Example: "Data classified Confidential must be encrypted at rest using AES-256." Standards are measurable and auditable.
  • Procedure gives step-by-step instructions for a task - who does what, in what order, with what records. Example: the key-rotation runbook.
  • Guideline is recommended, discretionary advice. Baseline is the minimum secure configuration applied to a system class.
  • Ownership: an accountable executive approves each policy; a named document owner maintains it. Documents carry version, approval date, effective date, and next review date.

Lifecycle and exceptions

  • Lifecycle: draft with stakeholders and legal, approve at the right authority, publish, communicate and obtain acknowledgement, enforce, monitor, review at least annually and on triggers such as incidents, regulatory change, or acquisitions, then retire.
  • Exceptions and waivers are risk decisions. A valid exception records the business justification, risk assessment, compensating controls, approver at the correct level, and a fixed expiry date, and is logged and reviewed.

Worked example

Marketing requests a consumer file-sharing service for campaign assets. The acceptable use policy prohibits unapproved data stores, and the standard lists approved services, so the request cannot simply proceed. An exception is raised: data is limited to Public and Internal classifications, the vendor supports MFA and encryption, sharing links expire, and DLP blocks Confidential content. The risk owner approves for six months with a review date and a compensating control of quarterly access review. When the team later asks to store regulated health data, the exception is refused and an approved alternative is offered, because the residual risk exceeds appetite and cannot be compensated.

Traps that cost marks

  • Writing procedures into a policy, producing a document nobody can enforce or maintain.
  • Publishing documents without an approver, version, or review date.
  • Granting permanent exceptions with no expiry or compensating control.
  • Failing to map documents to controls, so audit evidence cannot be located.
  • Omitting communication and acknowledgement records, which are the usual evidence of awareness.