Appendix I: Security Policy Templates

Chapter 26 taught the structure of governance documents — the policy / standard / procedure / guideline hierarchy, the policy lifecycle, and the discipline of a small, coherent, framework-mapped policy set. Chapter 27 built the risk register. Chapter 38 assembled everything Meridian had built into a board-ready program. This appendix gives you the templates behind all of it: the fill-in-the-blanks skeletons referenced throughout the Project Checkpoints, so you can produce the same artifacts for your own organization instead of starting from a blank page.

These are templates to customize, not finished documents. Every one below is a starting skeleton. They are deliberately generic; your organization's real documents must reflect your risk, your regulatory obligations, your roles, and your technology — and must be reviewed by the appropriate owners and (where applicable) legal counsel before they bind anyone. A template copied without thought is worse than no document, because it creates a false record of control (Chapter 26's warning: a policy nobody tailored or follows is fiction). Fill-in fields are shown as [BRACKETED PLACEHOLDERS]; guidance notes are set off in italics or callouts. Replace every bracket, delete every guidance note, and have the right owner approve the result before it is real.

Two conventions carry through, both straight from Chapter 26:

• Every document carries a header block. Owner, approver, approval date, review cadence, next review date, version. The single highest-leverage governance discipline (§26.5) is a tracked review date on every document; the header is where it lives. The standard header is:

  Document: [TITLE]                         Classification: [Internal / Confidential]
  Owner (accountable): [ROLE/NAME]          Version: [x.y]
  Approved by: [ROLE — see RACI]            Approval date: [YYYY-MM-DD]
  Review cadence: [annual / semi-annual]    Next review: [YYYY-MM-DD]
  Maps to: [framework function(s), e.g., NIST CSF: PROTECT; control IDs]

• Mandatory vs. recommended language is deliberate. Policies and standards use must / shall / will (binding). Guidelines use should / consider (advisory). Keep the tier honest: if changing a vendor, version, or keystroke would force you to edit the document, the detail belongs in a standard or procedure, not a policy (§26.2).

The templates below follow Meridian's policy spine from Figure 26.3. Use them in roughly the order shown; the Information Security Policy is the apex that authorizes everything beneath it.

1. Information Security Policy (apex) — outline

The top-level, board-approved policy that establishes intent and authorizes every document beneath it. Keep it high-level and technology-neutral so it survives years of technology change (§26.2). It states what and why, never how.

  [HEADER BLOCK]   Maps to: NIST CSF — GOVERN

  1. PURPOSE
     "[ORGANIZATION] protects the confidentiality, integrity, and availability of
      information and information systems commensurate with their sensitivity and the
      risks they face, in compliance with applicable law and contractual obligations."
     [State why this policy exists in 2–4 sentences. Reference the business mission.]

  2. SCOPE
     [Who and what this binds: all employees, contractors, and third parties acting
      on the organization's behalf; all information assets and systems, on-premises
      and cloud. Name any explicit exclusions.]

  3. POLICY STATEMENTS (high-level intent; one clause per domain)
     3.1  Information is classified and handled according to its sensitivity.
     3.2  Access is granted on the principle of least privilege and authenticated
          commensurate with risk.
     3.3  Systems are configured to approved secure baselines and kept patched.
     3.4  Security events are logged, monitored, and responded to.
     3.5  Risks are assessed, treated, and accepted only within the board-set appetite.
     3.6  Third-party and supply-chain risk is assessed and governed.
     3.7  Personnel receive security awareness training appropriate to their role.
     [Add/trim clauses to match your policy set; each clause is implemented by a
      topic policy and its standards.]

  4. ROLES & RESPONSIBILITIES
     [Reference the RACI (Template 10). Name: board oversight, the CISO's mandate
      (per the security charter), control owners, and every individual's duty.]

  5. ENFORCEMENT & EXCEPTIONS
     [State consequences of violation, and reference the exception process — a
      governed, time-boxed, owner-approved deviation is a tracked residual risk,
      not a silent violation (§26.5).]

  6. RELATED DOCUMENTS
     [List the topic policies this apex authorizes: AUP, Access Control, Data
      Classification, etc. — the policy index.]

  7. REVIEW
     [Restate the review cadence; "this policy is reviewed at least [annually]."]

Guidance: the apex policy should fit on a few pages. Resist putting numbers, products, or steps here — push those to standards and procedures so the board does not have to re-approve the policy when a version changes.

2. Acceptable Use Policy (AUP) — template

Binds employee and contractor behavior: what users may and may not do with the organization's systems, data, and accounts. This is the policy most often acknowledged by every employee (the annual "I have read and agree" that produces an audit trail — §26.5). Write it in plain language people will actually read.

  [HEADER BLOCK]   Maps to: NIST CSF — PROTECT / GOVERN

  1. PURPOSE & SCOPE
     [Why acceptable use matters; who it covers (all who access org systems).]

  2. ACCEPTABLE USE
     - Systems and accounts are provided for [business purposes]; [limited incidental
       personal use may be permitted — state your stance].
     - Users must protect credentials and use approved authentication (no sharing).
     - Users must report suspected security incidents and phishing promptly via
       [REPORTING CHANNEL].

  3. PROHIBITED USE  [the "do not" list — tailor to your environment]
     - Sharing accounts or credentials; bypassing security controls.
     - Installing unauthorized software; connecting unauthorized devices.
     - Accessing data without a legitimate business need (no "just curious" lookups).
     - Using organization systems for illegal activity, harassment, or [other].
     - Transmitting confidential data through unapproved channels or to personal
       accounts/storage.

  4. EMAIL, INTERNET & MESSAGING
     [Expectations for email, web, and collaboration tools; phishing-reporting duty.]

  5. DATA HANDLING
     [Reference the Data Classification Policy; state the duty to handle each class
      per its rules; remote-work and removable-media expectations.]

  6. BRING-YOUR-OWN-DEVICE (BYOD)  [if applicable]
     [Reference the mobile/BYOD standard (Ch.14): enrollment, minimum posture,
      containerization, the organization's right to wipe managed data.]

  7. MONITORING & PRIVACY
     [State plainly that systems may be monitored for security and compliance, within
      the limits of applicable law; set the expectation of privacy accordingly.
      ⚠️ Have legal/HR review this section — monitoring law varies by jurisdiction.]

  8. CONSEQUENCES
     [Violations may result in [disciplinary action up to termination] and, where
      applicable, legal action.]

  9. ACKNOWLEDGMENT
     [The statement each user signs/acknowledges, with date captured for evidence.]

⚠️ Common Pitfall: An AUP written in legalese no one reads is acknowledged but not internalized. Pair it with the awareness program (Template 9) so the behavior it asks for is actually taught, not just signed.

3. Access Control Policy — template

Implements the least-privilege and authentication clauses of the apex policy (Chapter 17 produced Meridian's). States who gets access to what, on what basis, and how it is reviewed. The specifics (MFA type, password length, review cadence) live in the standards beneath it, not here.

  [HEADER BLOCK]   Maps to: NIST CSF — PROTECT (Identity Management & Access Control)

  1. PURPOSE & SCOPE
     [Govern access to all information and systems for all identities — human and
      non-human (service accounts, workloads).]

  2. PRINCIPLES
     2.1  Least privilege: identities receive only the access needed for their role,
          and no more (Ch.17).
     2.2  Need-to-know: access to data requires a legitimate business need.
     2.3  Separation of duties: no single identity controls a whole risky process
          end-to-end (e.g., initiate vs. approve a wire transfer) (Ch.3, 26).
     2.4  Authentication commensurate with risk (Ch.16).

  3. ACCESS LIFECYCLE  (Joiner–Mover–Leaver — Ch.18)
     - Provisioning on hire/role start, based on role (RBAC) or attributes (ABAC).
     - Modification on role change (and removal of access no longer needed).
     - Timely deprovisioning on departure or contract end. [State the target SLA in
       the standard — orphaned accounts are a top breach cause (Ch.18).]

  4. AUTHENTICATION  [points to the Authentication Standard]
     - Phishing-resistant MFA required for [privileged / remote / all] access.
     - Password requirements per the Authentication Standard (not stated here).

  5. AUTHORIZATION MODEL  [points to the Authorization/RBAC Standard]
     - Access granted via roles/groups, not individual ad-hoc grants where possible.

  6. PRIVILEGED ACCESS  [points to the PAM Standard — Ch.19]
     - Privileged accounts are inventoried, vaulted, and granted just-in-time where
       feasible; sessions monitored.

  7. ACCESS REVIEWS  (certification — Ch.18)
     - Entitlements are reviewed at least [quarterly] by system/data owners;
       unapproved access is revoked within [SLA]. [Procedure in a separate runbook.]

  8. EXCEPTIONS
     [Governed, time-boxed, compensating-controlled, owner-approved — Ch.26.]

  9. RELATED STANDARDS
     [Authentication Std (Ch.16), Authorization/RBAC Std (Ch.17), PAM Std (Ch.19),
      Identity-lifecycle Std (Ch.18).]

4. Incident Response Plan — skeleton

The Respond/Recover capability from Chapter 24, structured on the NIST SP 800-61 lifecycle. An IR plan sets roles, severity, and the phases; detailed playbooks (per incident type) and runbooks (per task) hang beneath it. This skeleton is the plan; build playbooks separately.

  [HEADER BLOCK]   Maps to: NIST CSF — RESPOND / RECOVER

  1. PURPOSE, SCOPE & AUTHORITY
     [Why the plan exists; what incidents it covers; the authority of the incident
      commander to direct response, including to disconnect systems.]

  2. ROLES  (the incident team)
     - Incident Commander: [ROLE] — single point of command for an active incident.
     - Technical lead, comms lead, legal/compliance liaison, executive sponsor.
     - On-call / escalation: [who is paged, in what order].
     - [Map to your team; reference the RACI.]

  3. SEVERITY CLASSIFICATION
     [Define severity tiers (e.g., SEV-1 … SEV-4) by business impact, scope, and data
      sensitivity, with the response expectations and who is notified at each level.]
     | Severity | Definition (impact/scope)        | Notify        | Target response |
     |----------|----------------------------------|---------------|-----------------|
     | SEV-1    | [e.g., active breach of cust. data / core outage] | [exec + board?] | [immediate] |
     | SEV-2    | [significant, contained]          | [CISO + mgmt] | [< X hours]     |
     | SEV-3 …  | [moderate]                        | [SOC mgr]     | [< Y hours]     |

  4. LIFECYCLE PHASES  (NIST SP 800-61)
     4.1  Preparation — plan, tools, training, tabletops kept current.
     4.2  Detection & Analysis — triage an alert; confirm and scope; declare an
          incident; assign severity.
     4.3  Containment — short-term (stop the bleeding) and long-term; decide isolate
          vs. monitor (Ch.24's containment tradeoff).
     4.4  Eradication — remove the threat (malware, persistence, compromised creds).
     4.5  Recovery — restore from known-good; validate; monitor for recurrence.
     4.6  Post-Incident — blameless review; lessons learned feed back into prep.

  5. COMMUNICATIONS
     - Internal escalation tree and an out-of-band channel [in case primary comms
       are compromised — do not coordinate response on the breached email system].
     - External: legal, regulators, customers, law enforcement, cyber-insurer —
       WHO decides, WHEN, and WHO speaks. [⚠️ Breach-notification timelines are set
       by law/contract — capture your specific obligations with legal.]

  6. EVIDENCE & FORENSICS  (Ch.25)
     [Preserve evidence and chain of custody from the start; reference forensics
      readiness; note when to engage external DFIR.]

  7. PLAYBOOK INDEX
     [List the per-type playbooks: ransomware, BEC/phishing, account compromise,
      data exfiltration, lost device, vendor breach, etc.]

  8. TESTING
     [Tabletop and exercise cadence — at least [annually]; record results and
      improvements. Meridian ran a ransomware tabletop (Ch.24).]

🔗 Connection: Severity classification and the containment decision are the judgment calls Chapter 24 drilled. The plan is only as good as the rehearsal — schedule the tabletop, and treat a plan untested in over a year as unproven.

5. Risk Register — template (columns)

The spine of the whole program (Chapter 27, Chapter 38's "spine"). A living instrument, not a one-time spreadsheet. Every control exists to reduce a row here; every roadmap item maps to one. These are the columns; populate one row per identified risk.

Guidance: keep likelihood/impact scales defined in one place and applied consistently. Sort by inherent score to see the worst risks; but sequence treatment by risk-reduction-per-cost, not raw score (Ch.38's prioritization lesson). The register is reviewed on a cadence and reported to leadership as risk burndown.

6. Asset Inventory — template

"Tell me what we have" — Chapter 1's first instruction, and the foundation of the Identify function (Ch.38). You cannot protect, prioritize, patch, or report on what you do not know you have. One row per asset; tailor the asset types to your environment (endpoints, servers, network gear, cloud resources, applications, data stores, identities, OT devices).

Guidance: an inventory is only useful if it is current. Where possible, feed it from automated discovery (network, cloud, EDR, identity sources) and reconcile, rather than maintaining it by hand. The data-classification and criticality columns are what let the risk register and patch SLAs prioritize correctly.

7. Data Classification & Handling — template (companion to the inventory)

A short companion that defines the classes the inventory and AUP reference. Without defined classes, "encrypt sensitive data" is unenforceable hand-waving (§26.2's Defender's Lens).

  [HEADER BLOCK]   Maps to: NIST CSF — IDENTIFY / PROTECT

  CLASSES  [tailor labels and tiers to your organization]
  | Class         | Definition / examples                  | Handling (summary) |
  |---------------|----------------------------------------|--------------------|
  | Public        | Approved for public release            | No special handling |
  | Internal      | Default; internal business use         | Access-controlled  |
  | Confidential  | Sensitive business/customer data       | Encrypt; need-to-know |
  | Restricted    | Regulated data (e.g., cardholder, PHI, | Strong encryption, |
  |               | credentials)                           | strict access, log |

  HANDLING RULES PER CLASS  [reference standards, do not restate the numbers]
  - Encryption in transit/at rest per the Encryption Standard (Ch.4–5).
  - Storage, transmission, retention, and disposal rules per class.
  - Labeling expectations.

8. Vendor / Third-Party Risk Questionnaire — skeleton

The assessment instrument from Chapter 29's TPRM lifecycle: your risk includes your vendors' risk. This is a skeleton of question domains, sized to the vendor's risk tier — a vendor handling regulated data warrants far more scrutiny than a low-risk supplier. Customize depth by tier.

  [HEADER BLOCK]   Maps to: NIST CSF — GOVERN / IDENTIFY (Supply Chain Risk Mgmt)

  0. VENDOR & ENGAGEMENT CONTEXT
     [What service/data is involved? What classification of our data do they touch?
      What is their access to our environment? This sets the risk tier.]

  1. GOVERNANCE & PROGRAM
     - Do you have a documented information security program and a named security
       leader? Which framework(s) do you align to (e.g., NIST CSF, ISO 27001)?
     - Do you hold any attestations/certifications (e.g., SOC 2, ISO 27001)? [Request
       the report/certificate, do not just take the checkbox — Ch.28, Ch.29.]

  2. ACCESS CONTROL & IDENTITY
     - MFA on remote/privileged access? Least privilege? Joiner-mover-leaver process?

  3. DATA PROTECTION
     - Encryption in transit and at rest? Where is our data stored/processed
       (regions)? Data retention and secure disposal?

  4. VULNERABILITY & PATCH MANAGEMENT
     - Scanning cadence and patch SLAs? How are critical/exploited vulns handled?

  5. SECURITY OPERATIONS & LOGGING
     - Logging/monitoring? Detection and response capability?

  6. INCIDENT RESPONSE & BREACH NOTIFICATION
     - IR plan? Will you notify us of a breach affecting our data, and within what
       timeframe? [⚠️ This must also be in the CONTRACT, not just the questionnaire.]

  7. SUB-PROCESSORS (fourth-party risk — Ch.29)
     - Do you use sub-processors with access to our data? How do you govern them?

  8. SOFTWARE SUPPLY CHAIN  [if they provide software]
     - Do you provide an SBOM? Secure SDLC? Artifact signing / provenance (Ch.29, 31)?

  9. RESILIENCE
     - Backup, recovery, and business continuity? [Concentration risk — Ch.29.]

  EVIDENCE & SCORING
  [Request evidence for high-risk answers (reports, policies), not just yes/no.
   Score, set a risk tier, capture residual risk in the risk register, and define
   the monitoring cadence and contractual security requirements. The `vendor_risk`
   function (Ch.29 / Appendix B) scores a structured answer set.]

🔗 Connection: A questionnaire is a point-in-time snapshot. Chapter 29's lifecycle pairs it with continuous monitoring and contractual security requirements — the breach-notification clause especially belongs in the contract, where it is enforceable, not only in the questionnaire.

9. Patch / Vulnerability Remediation SLA — table

The risk-based patch SLAs from Chapter 23. The key lesson: severity alone is not priority — CVSS tells you how bad a vulnerability could be, but exploited-in-the-wild status (KEV), exploit probability (EPSS), and asset exposure tell you how urgent yours is. The table below is a starting SLA; calibrate the timeframes to your risk appetite, your exposure, and your operational reality, and escalate for actively exploited issues regardless of base score.

  GOVERNING RULES  [state alongside the table]
  - Priority = severity ADJUSTED by exploitation (KEV), exploit likelihood (EPSS),
    asset exposure, and asset criticality (Ch.23). An actively exploited "medium"
    can outrank a theoretical "critical."
  - The clock starts at [detection / vendor disclosure — define one].
  - Exceptions (cannot patch in SLA) follow the governed exception process: a
    documented, time-boxed risk acceptance with a compensating control and an owner
    (Ch.26). An unpatchable system with a virtual patch / segmentation is a managed
    risk; an unpatched system no one decided about is a silent one.
  - SLAs are measured and reported as a metric (Ch.36).

⚠️ Common Pitfall: Setting aggressive SLAs you cannot meet, then routinely missing them. An SLA the program consistently breaches is worse than an honest one it can keep — it trains everyone to ignore the policy. Set timeframes you can actually achieve, measure them, and tighten over time.

10. RACI (governance accountability) — template

The accountability matrix from §26.4: for each activity, exactly one Accountable (A) and at least one Responsible (R), plus Consulted (C) and Informed (I). Its chief value is exposing rows with zero or duplicate A's — orphaned controls. Customize the columns to your roles and the rows to your activities.

Guidance: scan the A column first — exactly one per row, no exceptions. "The security team owns it" is the language of an orphan (§26.4's war story: the most expensive breaches are often unowned controls, and the fix is a name in a cell). Add rows for every significant control; the board owns the direction-setting/oversight rows, the CISO owns the execution rows (governance vs. management).

11. Security Awareness Program — outline

The human-firewall program from Chapter 30. The core lesson: training that delivers knowledge fails; training that changes behavior and builds a reporting culture works. This is a program outline, not a single document.

  [HEADER BLOCK]   Maps to: NIST CSF — PROTECT (Awareness & Training)

  1. OBJECTIVES  (behavior, not just knowledge — Ch.30)
     - Increase the phishing REPORT rate (a leading indicator), not merely lower the
       click rate. A reported phish is a sensor working.
     - Build a no-blame reporting culture: reporting a mistake is rewarded, not punished.

  2. AUDIENCES & TAILORING
     - All staff: baseline (phishing, passwords/MFA, data handling, reporting how-to).
     - High-risk roles (finance, executives, admins, developers): role-specific
       modules (BEC and wire fraud, privileged-access hygiene, secure coding).
     - New hires: onboarding module + AUP acknowledgment (Template 2).

  3. DELIVERY
     - Recurring training on a [defined] cadence — short and frequent beats annual
       and long. Just-in-time nudges at the moment of risk where possible.
     - Phishing simulations run ETHICALLY (Ch.30): realistic but not cruel,
       used to teach and measure — never to shame or to set people up to fail.

  4. METRICS  (Ch.30, Ch.36 — measure what matters)
     - Report rate (primary), click rate, time-to-report, repeat-clicker trends,
       training completion. [The `click_rate` function — Ch.30 / Appendix B.]
     - Report up as a program metric; show the trend, not a single number.

  5. REPORTING CULTURE & CHAMPIONS
     - A frictionless reporting channel (e.g., a one-click report button) and a
       visible "thank you for reporting" loop.
     - A security-champions network to extend reach into teams.

  6. GOVERNANCE
     - Owner, review cadence, and linkage to the Security Awareness Policy.

  ⚖️ ETHICS NOTE: Phishing simulations and any monitoring tied to awareness must be
     run fairly and within applicable law and HR policy. The goal is a stronger human
     firewall, never a "gotcha." Punitive simulations destroy the reporting culture
     they are meant to build (Ch.30).

Putting the set together (the Chapter 38 assembly)

These templates are the parts. Chapter 38's lesson is that a stack of correct documents is not yet a program — coherence is. When you assemble them, apply the three disciplines from Chapters 26 and 38:

1. Everything traces up. Every standard links to a parent policy; every policy links to the apex Information Security Policy. An auditor can follow any control back to a board-approved mandate.
2. Everything maps across. Tag each document to a framework function (the Maps to: line in each header). The CSF functions — Govern, Identify, Protect, Detect, Respond, Recover — make coverage visible and gaps obvious (an empty function jumps out). This is the structure Figure 38.1 used to make the program legible to a board.
3. Everything is owned and reviewed. Every header names an accountable owner and a next-review date. The examiner's question — "who owns this, and when was it last reviewed?" — must have an answer in every document. That single discipline, more than any tool, is what separates a governed program from a pile of paper.

Keep the set small and hierarchical (Figure 26.3): a handful of policies, with detail pushed down into standards and procedures, beats a sprawl of forty narrow documents no one can keep current. Customize every template to your organization, have the right owner approve each, and treat them — as Chapter 26 insisted — as living instruments on a review cadence, not monuments carved once and left to rot.