Module 5 · Security Policy Architecture — Policy, Standard, Procedure, Baseline

Why this module exists. Auditors ask for “the policy.” Engineers want “the rule.” Both are right; they are asking different questions of different layers. A coherent policy architecture answers both without contradiction. This module is the four-layer model and the operational guidance for building each layer.

The four-layer model

Worked example — the chain in action

Take a concrete control: “encryption of data at rest.” The same control expressed at each layer:

• Policy (Data Protection Policy): “The organisation protects customer and employee personal data, financial data, and intellectual property from unauthorised disclosure, alteration, or destruction across its lifecycle.”
• Standard (Encryption Standard): “All persistent storage holding classified data shall be encrypted at rest using AES-256 in GCM or equivalent NIST-approved modes. Encryption keys shall be managed by an HSM-backed KMS. Keys shall be rotated at least annually.”
• Procedure (Database Provisioning Procedure): “When provisioning a new RDS instance, select the customer-managed key from the data-classification-appropriate KMS keyring. Confirm rotation policy is set to 365 days. Capture the KMS key ID in the asset register entry.”
• Baseline (Terraform module variables): storage_encrypted = true; kms_key_id = "arn:aws:kms:ap-south-1:..."; rotation_period_days = 365

Each layer answers the question its audience cares about. The auditor reads policy + standard. The engineer reads procedure + baseline. They never look at the wrong layer because each is written for a specific audience.

How many policies do you need?

The mistake is having too many. A practical Indian enterprise security policy set:

1. Information Security Policy (overarching, signed by the board)
2. Acceptable Use Policy
3. Data Protection / Privacy Policy (DPDP-aligned for Indian orgs)
4. Access Control Policy
5. Cryptography Policy
6. Incident Response Policy
7. Third-Party / Vendor Security Policy
8. Physical and Environmental Security Policy
9. Business Continuity Policy
10. Acceptable Encryption / Cryptography Standard — embedded or separate

That’s it. Ten policies, supported by 20-30 standards, 50-100 procedures, and continuously-evolving baselines. A 200-policy library is the sign of a control-by-document programme that does not work — nobody reads documents 50-200.

Where SOC 2, ISO 27001, RBI map in

Every external framework you map to lives in the standards and procedures layer, not the policy layer. The mapping is one-policy-to-many-controls. Worked example:

• The Access Control Policy maps to ISO 27001 A.5.15, NIST CSF PR.AA-01, RBI Cyber Security Framework Section 4.2, SOC 2 CC6.1, CC6.2, CC6.3.
• Each control reference cites a specific section of the policy + standard + procedure that satisfies it.
• The cross-reference matrix is what auditors use to navigate; the underlying documents do not change per framework.

Build the matrix in a spreadsheet maintained by the GRC function. Refresh quarterly. The cost of getting this right once is repaid in every audit cycle thereafter.

Versioning and lifecycle

• Single source of truth. Pick one platform — Confluence, SharePoint, GitLab Pages, or a GRC tool. Avoid duplication across systems.
• Version every document. Major.minor versioning. A clean changelog in the footer of every document. The auditor who asks “when was this last reviewed” should get the answer from the document itself, not from a separate register.
• Review cadence in calendar. Annual review for policy and standards, scheduled twelve months out, with a named reviewer.
• Exception register. Every deviation from a policy/standard is logged with a defined expiry. An exception without an expiry is a permanent change pretending to be temporary.

Common failure modes

• Policy that reads like a standard. “Passwords must be 12 characters with one uppercase, one symbol, etc.” is a baseline pretending to be policy. Policy says “the organisation enforces strong authentication”; the baseline says the character count.
• No procedure for the standard. “All databases must be encrypted at rest” with no procedure telling engineers how to provision an encrypted RDS / Postgres / MongoDB. The standard is unenforceable without the procedural translation.
• Procedures that are tribal knowledge. Senior engineer leaves; nobody knows how to rotate the KMS key. The procedure exists in their head; the document says “follow KMS rotation procedure” with no link.
• Annual review that is “approved without change”. If nothing has changed in a security standard for three years, either the threat landscape stopped moving or the review is theatre.

The Indian regulatory overlay

RBI Cyber Security Framework, SEBI CSCRF, IRDAI Information & Cyber Security Guidelines all prescribe specific policies as mandatory. The DPDP Rules add Privacy and Grievance procedures. Map the regulator’s prescribed policy list to your internal policy list and ensure 1:1 coverage. Missing-policy findings from regulators are the most-cited and easiest to avoid.

Key takeaways

• Four layers: policy (intent), standard (rule), procedure (steps), baseline (settings).
• Same control expressed differently at each layer for different audiences.
• Ten policies is enough; 200 is a smell.
• External-framework mappings live in standards/procedures, not in policy.
• Exception register with expiries; “approved without change” annual reviews are a red flag.