Policies are the foundational governance artifacts of every security program. A poorly written policy is worse than no policy — it creates false assurance, audit exposure, and compliance risk. This module teaches you to write policies that are clear, enforceable, auditable, and built to last.
Policies that are too vague cannot be enforced ("employees must protect company data"). Policies that are too specific become outdated with technology changes ("employees must use 128-bit AES encryption" — what about AES-256?). The skill is writing at the right level of abstraction: specific enough to be enforceable, general enough to survive technology evolution.
1. Title and version number. 2. Purpose (why this policy exists — the risk being managed). 3. Scope (who and what it covers). 4. Policy statements (mandatory "shall" language). 5. Standards references (specific technical requirements in separate standards). 6. Roles and responsibilities. 7. Exceptions process. 8. Enforcement and consequences. 9. Related documents. 10. Review and approval history.
"Shall" = mandatory requirement. No discretion. Violation creates compliance risk and auditable exposure. "Should" = recommended practice. Discretionary. "May" = optional permission. Avoid mixing modal verbs — inconsistency creates ambiguity about what is and is not required.
Title, version number, effective date, review date, owner, classification, and approval signatures. Version control is essential — auditors need to know which version was in effect during the period under review.
Explains WHY the policy exists in business terms. Links to the risk being managed. Example: "This policy exists to protect [Company] from the risk of unauthorized access to customer personal data, which could result in regulatory fines and reputational damage."
Precisely define who is covered (all employees, contractors, vendors), what is covered (all systems, specific data types, specific business processes), and any exclusions. Vague scope = unenforceable policy.
The core section. Numbered requirements using "shall" language. Each requirement should be a single obligation — avoid compound requirements ("Users shall use strong passwords and MFA" should be two separate requirements).
No policy can anticipate every situation. Define an exception process: request form, risk assessment requirement, approval authority, maximum duration (typically 30-90 days), and re-assessment requirement at expiry.
State the consequences of violation — without this section, policies are unenforceable. Reference the disciplinary policy. Specify that violations may result in termination, legal action, or regulatory reporting depending on severity.
Policies are living documents requiring active lifecycle management:
Triggered by: new risk identified, new regulation, audit finding, new technology deployment. Draft with subject matter experts. Circulate for stakeholder review. Legal review if required. CISO/executive approval.
Minimum annual review cycle. More frequent for high-change areas (cloud, AI, privacy). Review triggers: significant technology change, organizational restructure, regulatory change, audit finding related to the policy, security incident.
Maintain version history. Policy register tracks current and previous versions. Auditors need to verify which version was in effect during their audit period. GRC platforms (ServiceNow, Confluence) provide version control natively.
Policies that are superseded, no longer relevant, or merged with other policies must be formally retired. Retired policies are archived (not deleted) for regulatory evidence purposes. Communicate retirement to all stakeholders.
Exceptions are inevitable — legacy systems, business urgency, vendor constraints. A formal exception process prevents exceptions from becoming permanent unmanaged policy violations:
Standard form: What is the policy requirement? Why can it not be met? What is the business justification? What compensating controls will be applied? What is the requested duration? What is the residual risk?
Every exception is a risk acceptance. The risk manager assesses: what additional risk does this exception create? Is the compensating control adequate? Is the duration appropriate?
Match approval authority to exception risk level. Low-risk exceptions: CISO approval. High-risk exceptions: Executive committee. Exceptions to critical compliance requirements: Board approval required.
All exceptions are time-limited. Maximum 90 days per approval period. At expiry: either implement the required control, renew the exception (with re-assessment), or formally accept the risk. Expired exceptions with no action become unmanaged violations.
You are the GRC Manager at a 200-person fintech. The CISO has asked you to draft a complete Acceptable Use Policy (AUP) from scratch. Work through each policy component using proper governance anatomy — Purpose, Scope, Requirements, Roles, Exceptions, and Enforcement.