Security Policy Architecture — A Working Hierarchy

Last updated: April 29, 2026

The 217-page Word document that nobody read

A Gurgaon e-commerce company we audited had a magnificent Information Security Policy. 217 pages. Beautiful corporate language. Six different fonts somehow. The CISO had bought it from a consultancy in 2019 for ₹3.5 lakh.

During the audit, we asked the head of engineering one question: “What is your password rotation policy for production systems?”

He thought for a moment. “Every 90 days, I think? Or maybe 60?”

We checked. The policy said 90 days. The reality? Some systems had passwords from 2017. Others were rotated weekly because of a forgotten cron script. The shared admin password for the Magento backend had been the same for four years — long enough that two ex-employees, including one who left after a dispute, still knew it.

The CISO said something we hear constantly: “We have a policy. We just haven’t… operationalised it.”

The 217-page document was not the problem. The problem was that nobody — not the CISO, not the engineers, not the auditors who had stamped two prior cycles green — had ever asked the policy to do work. It was a paper artifact. It existed for compliance. The actual security of the system was held together by tribal knowledge, lucky defaults, and the occasional panic.

This module is about how to build security policies that do work — that auditors can trace to operational evidence, that engineers actually reference, that survive the next employee turnover. It is not about writing more pages. Most organisations need fewer pages, written better.

Why policies fail in practice

The dominant failure mode is not the absence of policies. It is policies that are unenforceable because they are too vague, too prescriptive, or too disconnected from how work actually happens.

The five patterns we see over and over in Indian implementations:

• The 200-page Word document. One mega-policy covering everything. New hires sign acknowledging they read it; nobody reads it.
• The template dump. A consultant delivered 30 policies on a Friday. Monday they were uploaded to SharePoint. They contradicted the operational runbooks the team actually used.
• The annual update theatre. Every March, someone changes the version number and date. No actual review. No actual changes.
• The shelfware policy. Policy says X. Reality is Y. The auditor asks about X; the engineer is told to “answer based on the policy.”
• The hostage-taker policy. The policy is so prescriptive that any deviation requires CISO sign-off, which means everyone deviates without sign-off.

An auditor friend in Bengaluru — she audits ISO 27001:2022 stage 2 audits for a Big-4 — told us once: “I can tell within 20 minutes whether a policy programme is real. I ask them to walk me through their last access review. If the answer involves opening a Word document and explaining what it says, the policy is theatre. If they show me a Jira ticket, a spreadsheet, a Slack thread, that is real.”

The four-tier policy hierarchy

The architecture that scales — recognised by ISO 27001, NIST, and every mature security programme — is a four-tier hierarchy. Each tier has a different audience, update cadence, and level of prescription.

Tier 1: Charter / governance statement

Top-level commitment from leadership. One to two pages. Signed by the CEO or board. Updated annually or on major organisational change.

What goes in it: that security is a leadership priority and resourced accordingly; the CISO or DPO reports to whom, with what independence; that the organisation will comply with applicable regulation (DPDP, RBI, sector-specific); the high-level governance bodies.

What goes wrong with it: the Mumbai NBFC’s charter said the CISO reported to the CEO. The actual reporting line was through the CIO, who decided what the CEO heard. When a 2024 incident escalated, the CEO learned about it 11 days after it started. Charter and reality must match — or auditors notice and so do regulators.

Tier 2: Policies

Statements of what the organisation does and requires. Each policy is 2 to 6 pages. Written in declarative present tense (“All employees use multi-factor authentication”). Stable for 12 to 24 months.

The minimum policy set for an Indian mid-market organisation is 17 documents. Not 30. Not 50. Resist the urge to write more — every policy is a maintenance liability.

• Information Security Policy — the umbrella commitment.
• Acceptable Use Policy — what employees and contractors can and cannot do with company assets.
• Access Control Policy — identity, authentication, authorisation, joiner-mover-leaver.
• Data Classification & Handling Policy — sensitivity tiers, labelling, handling per tier.
• Data Protection & Privacy Policy — DPDP-aligned commitments, Data Principal rights, retention.
• Cryptographic Controls Policy — when encryption is required, key management, approved algorithms.
• Asset Management Policy — inventory, ownership, lifecycle, disposal.
• Vulnerability Management Policy — scanning cadence, patching SLAs, exception handling.
• Change Management Policy — how changes are proposed, reviewed, approved, deployed.
• Incident Response Policy — what counts as an incident, who responds, escalation, notification.
• Business Continuity & Disaster Recovery Policy — RTO, RPO, testing.
• Supplier & Third-Party Security Policy — due diligence, DPAs, monitoring, termination.
• Physical & Environmental Security Policy — office, data centre, equipment.
• Secure Development Policy — SDL, code review, testing requirements.
• Cloud Security Policy — provider obligations, configuration baselines, monitoring.
• Logging & Monitoring Policy — what is logged, retention, who has access.
• Awareness & Training Policy — frequency, content, phishing simulation cadence.

Tier 3: Standards

Statements of how the organisation implements policy commitments. More prescriptive than policy, less prescriptive than procedure. Updated as technology evolves — every 6 to 12 months.

Story: A Pune SaaS company we audited had a Cryptographic Controls Policy that said “use industry-standard encryption.” That was it. The standard underneath it should have specified AES-256-GCM at rest, TLS 1.2 minimum (TLS 1.3 preferred), ECDH key exchange. It did not. So one team used DES (yes, DES) for an internal token-signing service “because it was faster.” The policy was not violated — it was vague enough to permit anything. Standards exist to make policy operational.

Examples of standards that do real work:

• Password & Authentication Standard — minimum length 12, no rotation if MFA is in place, FIDO2 mandatory for admins.
• Encryption Standard — AES-256-GCM at rest, TLS 1.2+ in transit, ECDH key exchange, RSA-3072 minimum.
• Cloud Configuration Standard — CIS Benchmark Level 1 baseline, no public S3 buckets, MFA on all root accounts.
• Endpoint Configuration Standard — disk encryption, screen lock, EDR agent, OS version floor.
• Vulnerability Severity & SLA Standard — Critical: 7 days, High: 30 days, Medium: 90 days, Low: best effort.

Tier 4: Procedures & runbooks

Step-by-step instructions for specific operational tasks. Owned by the team that does the work. Updated whenever the underlying tooling changes — sometimes monthly. Audience: practitioners doing the work.

Story: The Bengaluru fintech had an Incident Response Policy that said “incidents must be triaged within 4 hours.” Sounds good. But the runbook was missing. So when a real incident landed at 2am — a customer reported their account had been drained — the on-call engineer spent 90 of those 4 hours figuring out who to call, where logs lived, and whether he was authorised to suspend the account. The policy was followed in spirit and missed in operation. The runbook is what closes that gap.

Procedures live in the team’s working documentation — Confluence, Notion, GitHub wiki — not in the formal policy repository. They reference back to the policies and standards they implement.

How to write a policy people will actually follow

One section we wrote for a Hyderabad SaaS company’s Access Control Policy used to read like this:

“Access to information resources shall be granted in accordance with the principle of least privilege as may be reasonably required from time to time, with periodic reviews conducted as appropriate to ensure ongoing alignment with business requirements.”

We rewrote it as:

“Every employee, contractor, and service account has the minimum access needed to do their job. Access is reviewed quarterly by the system owner. Access not used in 90 days is automatically suspended. When someone changes role, their old access is removed within 5 working days. When someone leaves, all access is removed within 4 hours of their final shift.”

The first version is unfalsifiable. The second is a contract. An auditor can ask: show me the quarterly review. Show me the 90-day suspension log. Show me the leaver evidence from last month.

The pattern:

• Lead with the why. The first paragraph explains the risk and the business reason. Without this, the policy reads as theatre.
• One subject per policy. If a policy needs an internal table of contents, split it.
• Active voice, present tense. “All employees use MFA” — not “Multi-factor authentication shall be utilised by all personnel.”
• Bullet points, not paragraphs. Dense paragraphs of legal-style prose will not be read.
• Named owner per policy. Every policy lists the owner role (not person — roles outlive people).
• State the exception path. Without a documented exception process, every necessary deviation becomes a silent violation.
• Include the review cadence. “This policy is reviewed annually and on material change.”
• Map to controls. Reference the ISO 27001, SOC 2, DPDP, or RBI requirement(s) the policy addresses, so auditors can trace.

The metadata every policy should carry

• Policy title and unique identifier (e.g. POL-005-Access-Control)
• Version number and effective date
• Owner role and approver role
• Review cadence and next review date
• Scope (which entities, geographies, or systems it applies to)
• Related policies, standards, procedures
• Compliance mapping (ISO 27001 Annex A, SOC 2 CC, DPDP sections)
• Revision history (date, version, change summary, approver)

The exception process: where good intentions go to die

Every organisation has exceptions. The question is whether they are documented and time-bounded, or silent and permanent.

Story: A Mumbai BFSI client had a policy that said “no production access from personal devices.” A vendor support engineer needed emergency access at 3am from his home laptop. The CTO approved it on WhatsApp. Six months later, that “emergency” exception was still in place. The vendor had since changed staff. The current support engineer’s wife also used the laptop. Nobody had revoked the access.

A working exception process:

1. Requestor submits an exception with the specific control, reason, alternative compensating control, and expiry date (typically 90 days).
2. Risk owner reviews and either approves, rejects, or requests changes.
3. Approved exceptions are tracked in a register with owner, review date, and renewal status.
4. Exceptions expire automatically. Renewals require fresh justification.
5. The exception register is reviewed quarterly. Pattern exceptions (the same one requested repeatedly) trigger policy or process re-design.

The Mumbai client now uses a Jira workflow: every exception is a ticket with mandatory expiry date and approval chain. The “WhatsApp approval” path no longer exists.

Awareness and acknowledgement that actually works

Policies have no force if people are unaware of them. The minimum operational hygiene:

• New hires acknowledge the Acceptable Use and Information Security policies on day one. Recorded in the HRIS with timestamp.
• Annual re-acknowledgement of these two plus the Data Protection Policy.
• Role-specific policy acknowledgement: developers acknowledge the Secure Development Policy, admins the Privileged Access Policy, finance the financial-data handling standard.
• Policies accessible — searchable internal portal, not a SharePoint folder requiring three clicks.
• Quarterly micro-training (3 to 5 minute videos) on one policy theme.

One client of ours runs “Policy of the Month” — a 90-second internal video where a different team lead explains one policy clause in their own words and gives a war story. It has 90% engagement. Their compliance posture transformed in 18 months not because the policies changed but because people knew them.

The annual review cadence

• Continuous: Tier 4 procedures update as tooling changes.
• Quarterly: Review the exception register; identify pattern exceptions.
• Half-yearly: Review Tier 3 standards for technical drift (new algorithms, new compliance mandates).
• Annually: Review every Tier 2 policy. Confirm owner, scope, and that the policy still reflects intent. For most policies, the answer is “no change” — and that is fine.
• On trigger: Major regulatory change (DPDP Rules notification), significant incident, M&A, change in CISO, new product line.

Indian-context considerations

• DPDP alignment. Every policy that touches personal data references DPDP obligations explicitly. Data Protection Policy is the centrepiece, but Access Control, Data Classification, Logging, and Incident Response all carry DPDP touch-points.
• RBI / SEBI / IRDAI overlays. Regulated entities have prescribed requirements. Map policy clauses to specific regulatory clauses so audit traceability is one-click.
• Cross-border data transfer. Policy addresses Section 16 of DPDP and any sectoral restrictions (RBI on payments data, IRDAI on insurance data).
• Multilingual acknowledgement. For organisations with non-English-speaking workforces, policies should be available in regional languages. At minimum, an Acceptable Use summary and breach reporting procedure.
• CERT-In compliance. The April 2022 direction creates specific logging, retention, and incident reporting obligations that should be reflected in the Logging and Incident Response policies.

What good looks like in operational evidence

• A short, searchable internal policy portal. Not a SharePoint folder of Word documents.
• Each policy is one document, in markdown or wiki format, version-controlled.
• Acknowledgement records in the HRIS or training platform — tied to user identity, with completion timestamps.
• An exception register, currently active and recently reviewed.
• A traceability matrix mapping every ISO 27001 Annex A control (or SOC 2 CC, or DPDP section) to the policy clause that addresses it.
• Review meeting minutes showing actual discussion, not rubber-stamping.
• Procedures that reference policies, and policies that have measurable, observable controls.

Try this in your environment: write your first policy in 90 minutes

Pick the policy you most need. For most Indian organisations starting out, that is the Access Control Policy.

1. Minutes 0 to 15. Write the “why” paragraph. Three sentences. What risk does this policy address? Why does the business care? What would go wrong without it?
2. Minutes 15 to 45. Write the “what” — the actual rules. Use active voice, present tense, bulleted. Imagine showing it to an auditor. For each bullet, ask: can I prove this is happening? If not, rewrite or remove.
3. Minutes 45 to 60. Write the metadata header. Owner role. Review cadence. Compliance mapping to ISO 27001 A.5.15-A.5.18 and DPDP §8(5).
4. Minutes 60 to 75. Write the exception clause. Three sentences. Who can approve. What expires. How it is tracked.
5. Minutes 75 to 90. Read it aloud. If you get bored or confused, rewrite. Send it to one engineer who will be subject to it. Ask them: “Can you tell me what this requires you to do?” If they cannot, rewrite.

You now have a policy. It is two pages. It is operational. It is referenced. That is more security policy work than the 217-page Gurgaon document accomplished in five years.

Build the rest from there. One policy a week. In four months you have the full minimum set. In six months you have an exception register, acknowledgement records, and an audit trail. That is a working policy programme.