ISO 27001 A.5.1: Policies for Information Security

Quick Reference: A.5.1 in 60 Seconds

What the Control Asks For

ISO 27001:2022 A.5.1 Text

ISO 27001:2022 Annex A 5.1 asks organizations to define security and topic-specific policies, have management approve them, publish and communicate them to relevant personnel and relevant interested parties (such as customers and suppliers), have them acknowledged, and review them on a schedule and after major changes.

Clause 5.2 vs A.5.1. The top-level information security policy is a requirement of clause 5.2, which applies to every ISMS and cannot be excluded. A.5.1 adds topic-specific policies, communication and acknowledgement, and review. Clause 5.2 also asks for the policy to be available to interested parties, as appropriate.

Do you need this control?

A.5.1 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Almost every ISMS includes it: clause 5.2 already requires an information security policy, and A.5.1 adds topic-specific policies, approval, communication and review. What you can adapt is the number and shape of topic-specific policies: a small company may cover several topics in one document, as long as each is approved, communicated and reviewed.

ISO 27002:2022 Implementation Guidance (Section 5.1)

In our own words, ISO 27002 says:

1. A top-level information security policy, approved by top management, setting out your approach to information security. It should reflect your business strategy, your legal, regulatory and contractual obligations, and your current and expected risks and threats.
2. What that policy should say: what information security means for you; your security objectives, or how you set them; the principles that guide security work; a commitment to meet applicable requirements; a commitment to continually improve the ISMS; who is responsible for managing security; and how exemptions and exceptions are handled. Top management approves changes to it.
3. Topic-specific policies as needed, aligned with the top-level policy, for particular audiences or security areas. ISO 27002 gives twelve example topics (access control, physical security, asset management, information transfer, endpoint devices, network security, incident management, backup, cryptography, classification, vulnerability management, secure development). These are examples, not a required list.
4. Clear ownership: people with the right authority and expertise develop, review and approve each topic-specific policy.
5. Reviews at planned intervals and when things change: business strategy, technology, laws and contracts, risks, the threat landscape, and lessons from incidents. Reviews take account of management review and audit results, and related policies are kept consistent.
6. Communication to relevant personnel and interested parties in a form they can understand, with acknowledgement where applicable. Formats and names are up to you: some organisations put everything in one document, others call topic policies "standards".
7. Care when sharing externally, so a policy sent to customers or suppliers doesn't disclose confidential information.

What Auditors Actually Check

The Policy Hierarchy

┌─────────────────────────────────────────────────────────────┐
│  LEVEL 1: MASTER INFORMATION SECURITY POLICY                │
│  • Signed by CEO / Managing Director                        │
│  • High-level direction and commitment                        │
│  • Scope, objectives, responsibilities                        │
│  • References to all topic-specific policies                  │
│  • Reviewed annually by top management                        │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LEVEL 2: TOPIC-SPECIFIC POLICIES (as needed)               │
│  • Approved by CISO / Department Head                         │
│  • Detailed rules for specific domains                      │
│  • Each maps to Annex A controls and risk register            │
│  • Reviewed annually by policy owner                        │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LEVEL 3: PROCEDURES, STANDARDS, GUIDELINES                 │
│  • How to implement the policy (step-by-step)               │
│  • Technical standards (e.g., password length = 12)           │
│  • Guidelines (recommended but not mandatory)               │
│  • Owned by operational teams                               │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LEVEL 4: FORMS, TEMPLATES, CHECKLISTS                      │
│  • Practical tools for day-to-day compliance                  │
│  • Access request forms, incident report forms                │
│  • Audit checklists, risk assessment templates                │
│  • Owned by operational teams                               │
└─────────────────────────────────────────────────────────────┘

An Example Policy Set (Not an ISO Requirement)

ISO 27001 does not prescribe a list or a number of policies, and not every Annex A control needs its own policy. Decide which topic-specific policies you need from three inputs: your risk treatment plan, your legal and contractual obligations (A.5.31), and your audiences (staff, developers, suppliers, customers). The table below is one example set for a growing tech company; merge, split or drop topics to fit.

How small organisations adapt this: a 30-person company might have the top-level policy plus five to eight combined topic policies (for example one "Technology Use" policy covering acceptable use, endpoints and remote work). A regulated enterprise may have more, plus standards and procedures beneath them. Both can meet A.5.1.

The Master Information Security Policy

Master Policy Template

INFORMATION SECURITY POLICY
[Organization Name]
Version: 1.0
Approved by: [CEO Name], Managing Director
Date: [Date]
Review Date: [Date + 12 months]
Classification: Internal

---

1. PURPOSE AND SCOPE

1.1 Purpose
This policy establishes the framework for managing information security 
within [Organization Name]. It demonstrates management's commitment to 
protecting information assets and ensuring the confidentiality, integrity, 
and availability of information.

1.2 Scope
This policy applies to all employees, contractors, vendors, and third 
parties who access, process, store, or transmit [Organization Name] 
information assets. It covers all information systems, networks, devices, 
and physical locations.

1.3 Definition of Information Security
For [Organization Name], information security means protecting the
confidentiality, integrity and availability of information in any form,
and of the systems and services that handle it.

1.4 Objectives
Information security objectives are set each year by top management,
consistent with this policy, and are measurable where practicable
(clause 6.2). Examples:
• ≥ 95% of staff complete security awareness training each year
• 100% of leavers' access removed by their last working day
• Critical vulnerabilities on internet-facing systems fixed within 14 days
• Zero repeat findings from the previous internal audit
• Ensure compliance with applicable laws, regulations and contracts
• Continually improve the information security management system

2. MANAGEMENT COMMITMENT

2.1 Leadership Responsibility
Top management is committed to:
• Establishing and maintaining an effective Information Security Management System (ISMS)
• Providing necessary resources for information security
• Integrating information security into organizational processes
• Promoting continuous improvement in information security
• Supporting the information security roles defined in the organization

2.2 Information Security Governance
• The CISO is responsible for the overall information security program
• The Information Security Committee meets monthly to review security posture
• All departments are responsible for implementing security controls within their domain
• All employees are responsible for complying with security policies and procedures

3. POLICY FRAMEWORK

3.1 Policy Structure
This master policy is supported by topic-specific policies that provide 
detailed guidance on specific security domains. All policies are 
documented, approved, communicated, and reviewed as required by 
ISO 27001:2022 Annex A 5.1.

3.2 Topic-Specific Policies
The following policies support this master policy:
• Access Control Policy
• Asset Management Policy
• Acceptable Use Policy
• Change Management Policy
• Incident Response Policy
• Business Continuity Policy
• Supplier Security Policy
• [Complete list maintained in Policy Master Index]

3.3 Standards, Procedures, and Guidelines
Detailed implementation guidance is provided in standards, procedures, 
and guidelines that support the policies. These are maintained by the 
respective operational teams.

4. RISK MANAGEMENT

4.1 Risk Assessment
[Organization Name] conducts information security risk assessments at 
planned intervals and when significant changes occur. Risk assessments 
identify threats, vulnerabilities, and impacts to information assets.

4.2 Risk Treatment
Risks are treated according to the Risk Treatment Plan. Treatment options 
are risk modification, risk sharing, risk retention and risk avoidance 
(ISO/IEC 27005).

4.3 Risk Acceptance
Risk owners approve the risk treatment plan and accept residual risks 
(ISO 27001 clause 6.1.3). The CISO advises and records the decision. 
Accepted risks are monitored and reviewed regularly.

4.4 Exemptions and Exceptions
Any exception to this policy or a topic-specific policy is requested on 
the exception form, risk-assessed, time-limited, approved by the 
relevant risk owner and recorded in the exception register.

5. COMPLIANCE

5.1 Legal and Regulatory Compliance
[Organization Name] complies with all applicable laws and regulations, 
including but not limited to:
• [India's IT Act, 2000 and CERT-In Directions, 2022]
• [Digital Personal Data Protection Act, 2023 and DPDP Rules, 2025]
• [Sector rules, e.g. RBI, SEBI CSCRF, IRDAI, if applicable]
• [GDPR, if applicable]
• [PCI DSS, if applicable]
• [HIPAA, if applicable]
• [Any industry-specific regulations]

5.2 Contractual Compliance
[Organization Name] complies with all contractual security obligations 
to customers, partners, and suppliers.

5.3 Standard Compliance
[Organization Name] [maintains / is working towards] ISO 27001:2022 certification and aligns 
with industry best practices including NIST, CIS, and OWASP guidelines.

6. ROLES AND RESPONSIBILITIES

6.1 Top Management
• Approve information security policy and objectives
• Ensure resources are available for the ISMS
• Review ISMS performance at management reviews
• Promote security culture across the organization

6.2 CISO / Information Security Manager
• Develop and maintain the information security program
• Coordinate risk assessments and risk treatment
• Report security incidents to management
• Ensure compliance with security policies
• Conduct security awareness training

6.3 Department Heads
• Implement security controls within their department
• Ensure staff are aware of and comply with security policies
• Report security incidents and risks within their domain
• Support security audits and reviews

6.4 All Employees
• Comply with all information security policies and procedures
• Report security incidents immediately
• Protect information assets in their care
• Complete security awareness training
• Use information systems only for authorized purposes

6.5 IT Team
• Implement and maintain technical security controls
• Monitor systems for security incidents
• Respond to and investigate security incidents
• Maintain security configurations and patches

6.6 HR Team
• Include security requirements in employment contracts
• Conduct background checks as required
• Ensure security awareness training for new hires
• Coordinate security aspects of employee termination

7. SECURITY PRINCIPLES

7.1 Confidentiality
Information is accessible only to those authorized to have access. 
Access is granted based on business need and least privilege.

7.2 Integrity
Information is accurate and complete. Unauthorized modification of 
information is prevented. Changes are authorized and documented.

7.3 Availability
Information and systems are available when needed. Business continuity 
and disaster recovery plans ensure resilience.

7.4 Accountability
All access to information and systems is attributable to an individual. 
Logs and audit trails are maintained.

7.5 Least Privilege
Users and systems have the minimum access necessary to perform their 
functions. Privileges are reviewed regularly.

7.6 Defense in Depth
Multiple layers of security controls protect information assets. No single 
control is relied upon exclusively.

7.7 Security by Design
Security is considered in the design of all systems, processes, and 
services. Security is not an afterthought.

8. INCIDENT MANAGEMENT

8.1 Reporting
All security incidents must be reported immediately to the IT Security 
team or the CISO. No incident is too small to report.

8.2 Response
Security incidents are handled according to the Incident Response Policy. 
The response team investigates, contains, eradicates, and recovers from 
incidents.

8.3 Learning
Lessons learned from incidents are incorporated into the ISMS to prevent 
recurrence. Incident trends are reviewed at management reviews.

9. CONTINUOUS IMPROVEMENT

9.1 Monitoring and Measurement
The effectiveness of the ISMS is monitored and measured. Key performance 
indicators (KPIs) are tracked and reported to management.

9.2 Internal Audit
Internal audits of the ISMS are conducted at planned intervals to verify 
conformance and effectiveness.

9.3 Management Review
Top management reviews the ISMS at planned intervals to ensure its 
continuing suitability, adequacy, and effectiveness.

9.4 Corrective Action
Nonconformities are identified, documented, and corrected. Root causes 
are addressed to prevent recurrence.

10. POLICY REVIEW

10.1 Review Schedule
This policy is reviewed annually and when significant changes occur 
(e.g., mergers, acquisitions, new regulations, major incidents).

10.2 Review Process
The CISO initiates the review. Stakeholders provide input. Changes are 
approved by top management. The updated policy is communicated to all 
relevant personnel.

10.3 Version Control
All versions of this policy are archived. The current version is 
published in the document management system.

11. ACKNOWLEDGMENT

All employees, contractors, and third parties must acknowledge that they 
have read, understood, and agree to comply with this policy and all 
topic-specific policies. Acknowledgment is recorded in the HR system.

12. CONTACT

For questions about this policy, contact:
• CISO: [ciso@company.com]
• IT Security: [security@company.com]
• HR: [hr@company.com]

---

APPROVED BY:

[CEO Name]
Managing Director
Date: [Date]

[Board Member Name]
Board Member
Date: [Date]

[CISO Name]
Chief Information Security Officer
Date: [Date]

Topic-Specific Policies by Category

Category 1: Governance & Risk (A.5)

Information Security Roles & Responsibilities Policy

1. PURPOSE: Define information security roles and responsibilities
2. SCOPE: All personnel with security-related duties
3. KEY REQUIREMENTS:
   • CISO role defined and appointed
   • Security committee established and meeting monthly
   • Department security liaisons appointed
   • Roles and responsibilities documented in RACI matrix
   • Segregation of duties enforced (e.g., approver ≠ implementer)
   • No single person has unrestricted access to all systems
4. REVIEW: Annually by CISO

Risk Assessment & Risk Treatment Policy

1. PURPOSE: Define risk assessment methodology and treatment criteria
2. SCOPE: All information security risks
3. KEY REQUIREMENTS:
   • Risk assessments conducted annually and on significant change
   • Risk assessment methodology documented (likelihood × impact matrix)
   • Risk owners assigned for all identified risks
   • Risk treatment plan maintained and tracked
   • Residual risk is accepted by the risk owner, with documented justification
   • Residual risks monitored and reviewed quarterly
4. REVIEW: Annually by CISO

Category 2: Access & Identity (A.5.15-A.5.18, A.8.2-A.8.5)

Access Control Policy

1. PURPOSE: Control access to information and systems
2. SCOPE: All users, systems, and data
3. KEY REQUIREMENTS:
   • Access granted based on business need and least privilege
   • Unique user accounts for all individuals (no shared accounts)
   • MFA required for all remote access and privileged accounts
   • Access requests require approval from system owner
   • Access reviewed quarterly for privileged, annually for standard
   • Access revoked by the last working day (immediately for dismissals) and on role change
   • Password policy: 12+ characters, no forced rotation, breach detection
   • Session timeout: 30 minutes idle for standard, 15 minutes for privileged
4. REVIEW: Annually, and after significant change (access rights themselves are reviewed quarterly)

Category 3: Assets & Operations (A.5.9-A.5.13, A.8.1, A.8.9-A.8.14)

Asset Management Policy

1. PURPOSE: Identify, classify, and protect information assets
2. SCOPE: All information assets (hardware, software, data, services, people)
3. KEY REQUIREMENTS:
   • All assets registered in asset inventory
   • Assets classified by sensitivity (Public, Internal, Confidential, Restricted)
   • Asset owners assigned for all assets
   • Asset handling rules defined per classification
   • Asset disposal follows secure destruction procedures
   • Asset inventory reconciled monthly
4. REVIEW: Annually by CISO

Acceptable Use Policy

1. PURPOSE: Define acceptable use of organizational information systems
2. SCOPE: All employees, contractors, and third parties
3. KEY REQUIREMENTS:
   • Systems used for business purposes only
   • No unauthorized software installation
   • No sharing of passwords or credentials
   • No circumvention of security controls
   • No access to inappropriate or illegal content
   • Personal use permitted within reasonable limits (non-work browsing, etc.)
   • Social media usage guidelines defined
   • No confidential information on personal devices (unless BYOD enrolled)
4. REVIEW: Annually by CISO

Category 4: Development & Technology (A.5.31, A.8.25-A.8.32)

Secure Development Policy

1. PURPOSE: Ensure security in software development lifecycle
2. SCOPE: All software development, DevOps, and engineering teams
3. KEY REQUIREMENTS:
   • Security requirements defined in all projects
   • Threat modeling conducted for all new applications
   • Secure coding standards enforced (OWASP Top 10 mitigation)
   • Code review includes security checks
   • SAST/SCA/DAST scanning in CI/CD pipeline
   • No secrets in source code (pre-commit hooks, vault integration)
   • Penetration testing before production release
   • Security champions on every development team
4. REVIEW: Annually by CISO + CTO

Change Management Policy

1. PURPOSE: Control changes to information systems and services
2. SCOPE: All changes to production systems, networks, and applications
3. KEY REQUIREMENTS:
   • All changes require approval via Change Advisory Board (CAB)
   • Emergency changes require post-hoc approval within 24 hours
   • Changes tested in non-production environment before deployment
   • Rollback plan documented for all changes
   • Changes to security configurations require security team approval
   • Change records maintained with who, what, when, why
   • Standard changes pre-approved and documented
4. REVIEW: Annually by CISO + IT Director

Category 5: Incident & Continuity (A.5.24-A.5.30, A.6.8, A.8.15-A.8.17)

Incident Response Policy

1. PURPOSE: Define incident response procedures
2. SCOPE: All information security incidents
3. KEY REQUIREMENTS:
   • All incidents reported within 1 hour of discovery
   • Incident response team activated within 2 hours
   • Incident classification: Low, Medium, High, Critical
   • Incident containment within 4 hours for Critical incidents
   • Evidence preservation for forensic investigation
   • Communication plan for internal and external stakeholders
   • Post-incident review within 72 hours
   • Lessons learned incorporated into ISMS
4. REVIEW: Annually by CISO

Business Continuity & Disaster Recovery Policy

1. PURPOSE: Ensure business continuity and rapid recovery
2. SCOPE: All critical business processes and systems
3. KEY REQUIREMENTS:
   • Business Impact Analysis (BIA) conducted annually
   • Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) defined
   • Backup strategy: daily incremental, weekly full, monthly archive
   • Backup tested quarterly (restore verification)
   • Disaster recovery plan tested annually
   • Alternate work location defined for critical functions
   • Communication plan for business disruption
   • Crisis management team established
4. REVIEW: Annually by CISO + Operations Director

Category 6: Third-Party & Supply Chain (A.5.19-A.5.23)

Supplier Security Policy

1. PURPOSE: Ensure security in third-party relationships
2. SCOPE: All suppliers, vendors, contractors, and service providers
3. KEY REQUIREMENTS:
   • Security requirements in all supplier contracts
   • Supplier risk assessment before engagement
   • Supplier security audits for high-risk vendors
   • Access granted to suppliers on least-privilege basis
   • Supplier access reviewed quarterly
   • Incident notification requirements in contracts
   • Termination procedures include access revocation and data return
   • Cloud supplier security requirements defined (shared responsibility)
4. REVIEW: Annually by CISO + Procurement

Category 7: Physical & Human (A.6.1-A.6.8, A.7.1-A.7.14)

Physical Security Policy

1. PURPOSE: Protect physical assets and premises
2. SCOPE: All offices, data centers, and physical locations
3. KEY REQUIREMENTS:
   • Access control to premises (badge, biometric, or key)
   • Visitor registration and escort required
   • Secure areas for sensitive equipment and documents
   • CCTV monitoring of entry points
   • Environmental controls (fire suppression, climate control)
   • Equipment protection (cable locks, secure storage)
   • Clear desk and clear screen policy enforced
   • Equipment disposal through approved vendor
4. REVIEW: Annually by Facilities Manager + CISO

Human Resources Security Policy

1. PURPOSE: Ensure security in employment lifecycle
2. SCOPE: All employees, contractors, and temporary staff
3. KEY REQUIREMENTS:
   • Security clauses in employment contracts
   • Background verification for all personnel, proportionate to role, access and applicable law
   • Security awareness training during onboarding
   • Security responsibilities in job descriptions
   • Return of assets upon termination
   • Access revocation on last day of employment
   • Exit interview includes security discussion
   • Disciplinary process for security violations
4. REVIEW: Annually by HR + CISO

Category 8: Cryptography & Communications (A.8.12, A.8.20-A.8.24)

Cryptography Policy

1. PURPOSE: Ensure effective use of cryptographic controls
2. SCOPE: All cryptographic implementations
3. KEY REQUIREMENTS:
   • Approved algorithms: AES-256-GCM, RSA-4096, ECDSA P-384, SHA-256
   • Prohibited algorithms: MD5, SHA-1, DES, 3DES, RSA-1024
   • TLS 1.2 minimum, TLS 1.3 preferred, for all external connections
   • Key management: HSM or KMS for all production keys
   • Key rotation: annually for encryption keys, 90 days for API keys
   • Certificate management: automated renewal, CA selection
   • No custom cryptography
   • Cryptographic modules validated (FIPS 140-3 where required)
4. REVIEW: Annually by CISO + Security Architect

Network Security Policy

1. PURPOSE: Protect network infrastructure and traffic
2. SCOPE: All networks, firewalls, VPNs, and network devices
3. KEY REQUIREMENTS:
   • Network segmentation (DMZ, internal, management, guest)
   • Firewall rules: default deny, explicit allow only
   • VPN required for all remote access
   • Wi-Fi: WPA3-Enterprise, no shared passwords
   • Intrusion Detection/Prevention Systems (IDS/IPS) on all segments
   • Network traffic monitoring and logging
   • Regular firewall rule review (monthly)
   • Network device hardening per vendor benchmarks
4. REVIEW: Quarterly by Network Security Lead + CISO

Category 9: Monitoring & Compliance (A.5.31-A.5.37, A.8.15-A.8.17)

Monitoring & Logging Policy

1. PURPOSE: Ensure adequate monitoring and logging of security events
2. SCOPE: All systems, applications, and networks
3. KEY REQUIREMENTS:
   • All security events logged (success and failure)
   • Logs include: timestamp, user, action, source, result, object
   • Logs centralized in SIEM with 1-year retention
   • Real-time alerting for critical events
   • Log integrity protected (tamper-resistant storage)
   • Regular log review (daily for critical, weekly for standard)
   • Clock synchronization across all systems (NTP)
   • Audit trail for all administrative actions
4. REVIEW: Annually by CISO + SOC Manager

Compliance & Legal Policy

1. PURPOSE: Ensure compliance with legal, regulatory, and contractual requirements
2. SCOPE: All applicable compliance obligations
3. KEY REQUIREMENTS:
   • Compliance register maintained with all applicable requirements
   • Regular review of new and changed regulations
   • Legal review of all contracts with security clauses
   • Intellectual property protection
   • Records retention per legal requirements
   • Privacy and data protection compliance
   • Independent review of ISMS (internal audit)
   • Compliance violations reported and remediated
4. REVIEW: Annually by CISO + Legal Counsel

Policy Writing Best Practices

The CLEAR Policy Framework

Policy Structure Template (Topic-Specific)

POLICY NAME — [Organization Name]

1. PURPOSE
   One sentence explaining why this policy exists.

2. SCOPE
   Who and what this policy applies to.

3. DEFINITIONS
   Key terms used in this policy.

4. POLICY STATEMENT
   The main rules and requirements (bullet points, numbered).

5. ROLES AND RESPONSIBILITIES
   Who does what (Policy Owner, IT Security, All Users, etc.).

6. COMPLIANCE
   What happens if someone doesn't comply (disciplinary action, etc.).

7. RELATED POLICIES AND DOCUMENTS
   Links to related policies, standards, and procedures.

8. REVIEW AND APPROVAL
   Owner: [Name]
   Approved by: [Name, Title]
   Date: [Date]
   Review Date: [Date + 12 months]
   Version: [X.Y]
   Classification: [Internal / Confidential]

Policy Language Guide

Policy Governance Framework

Policy Governance Structure

┌─────────────────────────────────────────────────────────────┐
│  POLICY GOVERNANCE BOARD                                    │
│  • Meets quarterly                                          │
│  • Reviews policy effectiveness                             │
│  • Approves new and revised policies                        │
│  • Members: CEO, CISO, Legal, HR, IT Director               │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  POLICY OWNER COUNCIL                                       │
│  • Meets monthly                                            │
│  • Reviews policy metrics and compliance                      │
│  • Coordinates policy updates                                 │
│  • Members: All policy owners                               │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  POLICY OWNERS (per policy)                                 │
│  • Responsible for policy content                             │
│  • Ensures policy is current and accurate                     │
│  • Coordinates policy review and update                       │
│  • Reports compliance metrics to Policy Council               │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  POLICY ADMINISTRATOR                                       │
│  • Maintains policy repository                                │
│  • Tracks acknowledgment rates                                │
│  • Coordinates distribution and communication                 │
│  • Archives old versions                                      │
└─────────────────────────────────────────────────────────────┘

Policy Master Index

Policy Approval & Management Review

Approval Workflow

┌─────────────────────────────────────────────────────────────┐
│  STEP 1: DRAFT                                              │
│  • Policy Owner drafts or updates policy                      │
│  • Legal review for regulatory compliance                     │
│  • Security review for technical accuracy                   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  STEP 2: REVIEW                                             │
│  • Stakeholder review (2-week comment period)                │
│  • Feedback incorporated                                    │
│  • Final draft prepared                                     │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  STEP 3: APPROVE                                            │
│  • Master policy: CEO / Board approves                        │
│  • Topic-specific: CISO or Department Head approves          │
│  • Approval recorded (signed, dated, versioned)             │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  STEP 4: PUBLISH                                            │
│  • Upload to policy repository (intranet, SharePoint, etc.)  │
│  • Update Policy Master Index                                 │
│  • Archive old version                                      │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  STEP 5: COMMUNICATE                                        │
│  • Email announcement to all staff                           │
│  • Slack/Teams notification                                   │
│  • All-hands meeting presentation (for major changes)        │
│  • New hire onboarding includes policy review                 │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  STEP 6: ACKNOWLEDGE                                        │
│  • Staff acknowledge within 30 days                           │
│  • Reminders at 15 days, 25 days                            │
│  • Manager follow-up at 30 days for non-acknowledged         │
│  • Access to systems blocked after 45 days without acknowledgment│
└─────────────────────────────────────────────────────────────┘

Management Review Agenda (Annual)

Policy Communication & Distribution

Communication Channels

Policy Distribution Checklist

• Policy uploaded to central repository
• Policy indexed in Policy Master Index
• Email announcement sent to all staff
• Slack/Teams notification posted
• Old version archived with redirect
• Manager briefing pack prepared (key changes, talking points)
• FAQ document prepared for common questions
• Training material updated (if policy change requires new behavior)
• Systems updated (if policy change requires technical enforcement)
• Acknowledgment campaign launched

Policy Acknowledgment & Tracking

Acknowledgment Methods

Acknowledgment Tracking Dashboard

┌──────────────────────────────────────────────────────────────┐
│  POLICY ACKNOWLEDGMENT DASHBOARD — June 2026                │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  Master Policy              100% ██████████████████████    │
│  Access Control Policy       98% █████████████████████░     │
│  Acceptable Use Policy      100% ██████████████████████    │
│  Incident Response Policy    96% ████████████████████░░      │
│  BYOD Policy                 94% ████████████████████░░░      │
│  Secure Development Policy   92% ███████████████████░░░░      │
│                                                              │
├──────────────────────────────────────────────────────────────┤
│  NON-ACKNOWLEDGED (Action Required)                          │
│  • 3 employees >45 days on BYOD Policy → Access restricted  │
│  • 5 employees >30 days on Secure Development → Manager alert │
│  • 2 contractors >30 days on Access Control → HR follow-up   │
├──────────────────────────────────────────────────────────────┤
│  NEW HIRE ACKNOWLEDGMENT                                    │
│  • 5 new hires this month → 4/5 acknowledged (80%)          │
│  • 1 pending → Onboarding reminder sent                        │
└──────────────────────────────────────────────────────────────┘

Escalation for Non-Acknowledgment

Policy Review & Maintenance

Review Triggers

Review Process

┌─────────────────────────────────────────────────────────────┐
│  1. INITIATE                                                │
│  • Policy Administrator notifies owner 30 days before review │
│  • Owner reviews current policy, incidents, changes, risks  │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  2. GATHER INPUT                                            │
│  • Incident trends related to this policy                   │
│  • Audit findings related to this policy                    │
│  • Staff feedback and questions                             │
│  • Industry changes and new threats                         │
│  • Legal and regulatory changes                             │
│  • Technology changes                                       │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  3. UPDATE                                                  │
│  • Owner drafts updated policy                              │
│  • Legal review (if regulatory changes)                     │
│  • Security review (if technical changes)                   │
│  • Stakeholder review (2-week comment period)             │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  4. APPROVE                                                 │
│  • Approval by appropriate management level                  │
│  • Version number incremented                               │
│  • Approval recorded                                        │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  5. COMMUNICATE                                             │
│  • Changes summarized in announcement                       │
│  • New version published                                     │
│  • Old version archived                                     │
│  • Staff re-acknowledge if significant changes              │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  6. DOCUMENT                                                │
│  • Review meeting minutes recorded                           │
│  • Policy Master Index updated                               │
│  • Audit trail maintained                                    │
└─────────────────────────────────────────────────────────────┘

Policy Exception Management

Exception Request Template

POLICY EXCEPTION REQUEST

Policy: ________________________________
Requester: ________________________________
Date: ________________________________

1. EXCEPTION JUSTIFICATION
   Why is this exception needed? What business function requires it?
   ________________________________

2. SCOPE OF EXCEPTION
   Who: ________________________________
   What systems: ________________________________
   Duration: ________________________________
   What specific policy requirement is being excepted:
   ________________________________

3. RISK ASSESSMENT
   Risk if exception granted: ________________________________
   Likelihood: ☐ Low ☐ Medium ☐ High
   Impact: ☐ Low ☐ Medium ☐ High
   Overall Risk: ☐ Low ☐ Medium ☐ High

4. COMPENSATING CONTROLS
   What additional controls will be implemented to mitigate risk?
   ________________________________

5. APPROVAL
   Requester: ________________ Date: ____________
   Manager: ________________ Date: ____________
   CISO: ________________ Date: ____________
   (Exceptions assessed as High risk require approval by top management as well as the risk owner)

6. REVIEW DATE
   Exception expires on: ________________________________
   Quarterly review required: ☐ Yes ☐ No

Exception Register

Policy-as-Code & Automation

Policy-as-Code Implementation

Git-Based Policy Repository Structure

policies/
├── README.md                    # Policy repository overview
├── master-policy.md             # Master Information Security Policy
├── policy-master-index.md       # Index of all policies
├── governance/
│   ├── policy-governance-framework.md
│   ├── policy-review-schedule.md
│   └── exception-register.md
├── organizational/
│   ├── information-security-roles.md
│   ├── risk-assessment-policy.md
│   └── compliance-legal-policy.md
├── access/
│   ├── access-control-policy.md
│   ├── acceptable-use-policy.md
│   └── byod-policy.md
├── assets/
│   ├── asset-management-policy.md
│   ├── data-classification-policy.md
│   └── backup-recovery-policy.md
├── development/
│   ├── secure-development-policy.md
│   └── change-management-policy.md
├── operations/
│   ├── incident-response-policy.md
│   ├── business-continuity-policy.md
│   └── monitoring-logging-policy.md
├── third-party/
│   └── supplier-security-policy.md
├── physical/
│   ├── physical-security-policy.md
│   └── remote-working-policy.md
├── technical/
│   ├── cryptography-policy.md
│   ├── network-security-policy.md
│   ├── malware-protection-policy.md
│   └── vulnerability-management-policy.md
└── human-resources/
    └── hr-security-policy.md

Policy Metrics & KPIs

Policy Governance Scorecard

Industry-Specific Policy Packs

Healthcare Policy Pack (add to your base set)

Financial Services Policy Pack (add to your base set)

SaaS / Technology Policy Pack (Add to Base 25)

Government / Defense Policy Pack (Add to Base 25)

Policy Audit Evidence

Audit Evidence Checklist

Implementation Roadmap: 4 Weeks

90-Day Policy Sprint (New ISMS)

Common Audit Failures & How to Fix Them

Lessons from Public Breaches

The cases below are real, public breaches. The points drawn from them stay within what the published reports say.

Equifax (2017)

What the public record shows: attackers exploited a known Apache Struts vulnerability that had not been patched across all systems. The US House Oversight Committee report (December 2018) found failures of process and accountability: the patch notice did not reach the right owner, scans missed the vulnerable system, and an expired certificate had blinded a traffic-inspection tool for months.

Lessons for A.5.1:

• A patch policy is not enough on its own; it needs clear ownership and follow-up
• Policies should say who is accountable, and be checked for effectiveness (A.5.36)

Twitter (2020)

What the public record shows: the New York Department of Financial Services report (October 2020) describes attackers phoning employees, posing as IT staff, and capturing their credentials and MFA codes on a fake VPN site, then using internal tools to take over high-profile accounts.

Lessons for A.5.1:

• Policies need to address social engineering and the protection of privileged internal tools
• Policies should be reviewed after incidents (a review trigger ISO 27002 lists)

A hypothetical Indian composite

Scenario: a 200-person Bengaluru SaaS company has a policy set copied from a template. Its access control policy promises quarterly access reviews that nobody performs, and nobody owns the policy. A customer's due-diligence audit finds former contractors with live accounts.

Lessons for A.5.1:

• Every policy needs an owner and a review date
• Do not promise in a policy what you will not do; auditors test what the policy says

Multi-Framework Mapping

FAQ

How many policies do we need for ISO 27001?

ISO sets no number. You need the information security policy (clause 5.2) plus the topic-specific policies your risks, legal duties and audiences require. ISO 27002 lists twelve example topics. The exact number depends on your organization size, industry, and risk profile. Small businesses can merge related topics (e.g., Remote Working + BYOD). Large enterprises may need specialized policies (AI Governance, Cloud Security, etc.).

Can we use generic policy templates?

No, templates are a starting point, not a finish line. Auditors reject copy-paste policies that don't reflect your actual environment. Every policy must be tailored to your organization, technology, risks, and culture. Use templates as a foundation, then customize extensively.

Does the CEO need to approve every policy?

No, only the master policy requires top management approval. Topic-specific policies can be approved by the CISO, department head, or other appropriate management level. The master policy is the "constitution", topic-specific policies are the "laws."

What happens if someone doesn't acknowledge a policy?

Escalate: First reminder at 15 days, second at 25 days, manager follow-up at 30 days, system access restricted at 45 days, HR involvement at 60 days. This is a governance issue, not just a compliance checkbox.

How often should policies be reviewed?

At planned intervals (most organisations choose annually) and when significant changes occur. For example, review when:

• New regulations are enacted
• Major incidents occur
• New technologies are adopted
• Significant organizational changes happen
• Customer requirements change
• Audit findings identify gaps

What is the fastest path to A.5.1 compliance?

1. Week 1: Draft master policy (use our template, customize for your org)
2. Week 2: Draft top 10 topic-specific policies (Access Control, Asset Management, Incident Response, etc.)
3. Week 3: Get management approval, publish to intranet
4. Week 4: Launch acknowledgment campaign, track compliance

This gets you to 80% compliance in 4 weeks. The remaining 20% (additional policies, procedures, metrics) takes 4-8 weeks.

How much effort does a policy set take?

Plan for roughly 80–120 hours to tailor templates for a growing company, plus 20–40 hours of management time for review and approval, and a legal review of any clauses with legal effect. The effort depends far more on how many policies you genuinely need, and how much you tailor them, than on the template you start from.

Can we use Notion, Confluence, or SharePoint for policy management?

Yes, any document management system works. The key requirements are:

• Version control (can see old versions)
• Access control (staff can read, only owners can edit)
• Searchability (staff can find policies)
• Audit trail (who changed what, when)
• Distribution (everyone can access)

Avoid storing policies only in email or file shares, they get lost and outdated.

Industry-Specific Policy Frameworks

Banking and Financial Services (BFSI)

RBI Cyber Security Framework Requirements:

• Cyber Security Policy: Complete policy covering governance, risk management, incident response, and business continuity. Must be board-approved and reviewed annually.
• Access Control Policy: Role-based access with segregation of duties. Four-eyes principle for critical transactions. Mandatory MFA for all systems.
• Customer Data Protection Policy: Explicit consent for data collection, purpose limitation, data minimization, and retention schedules. Alignment with DPDP Act 2023.
• Vendor Risk Management Policy: All third-party vendors must be assessed, contracted with security clauses, and monitored continuously.
• Incident Response Policy: 6-hour reporting to RBI for serious incidents. Defined escalation paths to board and regulators.
• Policy-Specific Evidence: RBI auditors expect to see policy documents, approval records, distribution logs, training records, and violation tracking.

BFSI Policy Architecture:

Master Information Security Policy (Board-approved)
├── Cyber Security Policy
├── Access Control and Identity Management Policy
├── Customer Data Protection Policy
├── Vendor Risk Management Policy
├── Incident Response and Reporting Policy
├── Business Continuity and DR Policy
├── IT Operations and Change Management Policy
├── Physical Security Policy
├── Asset Management Policy
├── Cryptographic Controls Policy
├── Monitoring and Logging Policy
└── Compliance and Audit Policy

Healthcare

NABH and Health Data Management Requirements:

• Patient Data Privacy Policy: Consent management, data anonymization for research, patient rights (access, correction, deletion).
• Medical Records Management Policy: Retention per applicable rules (the IMC Professional Conduct Regulations 2002 set 3 years for in-patient records; state rules and medico-legal practice often require longer), access logging, and secure disposal.
• Medical Device Security Policy: IoT device inventory, patch management, network segmentation, and incident reporting.
• Third-Party Disclosure Policy: Rules for sharing patient data with insurance companies, government health programs, and research institutions.
• Breach Notification Policy: CERT-In within 6 hours for listed incidents; under the DPDP Act and Rules, intimation to the Data Protection Board and each affected patient without delay, with a detailed report to the Board within 72 hours (from about May 2027). US HIPAA, if relevant: without unreasonable delay and within 60 days.

Healthcare Policy Challenges:

• Clinical vs. Administrative Balance: Policies must not impede patient care. Doctors need rapid access to records during emergencies.
• Research Data Use: Policies must allow anonymized data use for research while protecting individual privacy.
• Telemedicine: New policies needed for virtual consultations, digital prescriptions, and remote patient monitoring data.

Government and Public Sector

MeitY and NCIIPC Requirements:

• National Cyber Security Policy Alignment: Government organizations must align with national cyber security strategy.
• Classification-Based Policies: Different handling for Top Secret, Secret, Confidential and Restricted information (the Indian government marking scheme), plus corporate levels for unclassified information.
• Citizen Data Protection: Policies protecting Aadhaar, PAN, tax records, and other citizen data. Strict compliance with DPDP Act 2023.
• Procurement Security Policies: Security requirements embedded in all IT procurement tenders.
• Incident Reporting: Mandatory reporting of specified cyber incidents to CERT-In within 6 hours of noticing them, for all service providers, intermediaries, data centres, body corporates and government organisations (CERT-In Directions, 28 April 2022).

Government Policy-Specific Requirements:

• Hindi/Local Language: Policies must be available in Hindi and relevant local languages for field offices.
• Accessibility: Policies must comply with accessibility standards for employees with disabilities.
• Record Retention: Government records often require permanent retention. Policies must address long-term archival and format migration.
• RTI Compliance: Policies must balance transparency (Right to Information Act) with security.

IT/ITeS and SaaS

Multi-Tenant and Cloud-Specific Policies:

• Data Residency Policy: Customer data storage location requirements, data transfer rules, and cross-border restrictions.
• Tenant Isolation Policy: Technical and procedural controls ensuring no cross-tenant data access.
• API Security Policy: Authentication, rate limiting, input validation, and logging for all APIs.
• Customer Key Management Policy: Procedures for customer-managed encryption keys (CMEK) and key rotation.
• Service Level Policy: Security-related SLAs (uptime, incident response time, patch timelines).
• Bug Bounty and Disclosure Policy: Rules for accepting security vulnerability reports from external researchers.

SaaS Policy Challenges:

• Rapid Change: SaaS products change weekly. Policies must be agile without being vague.
• Customer Variability: Enterprise customers may require custom security policies. Balance standardization with flexibility.
• Global Compliance: SaaS serving multiple countries must comply with GDPR, DPDP Act, CCPA, and others simultaneously.

Manufacturing and Industrial

OT/IT Convergence Policies:

• OT Security Policy: Separate policy for industrial control systems, SCADA, and PLCs. Air-gap requirements, patch management restrictions, and physical security.
• Intellectual Property Protection Policy: CAD files, product designs, and manufacturing processes. DLP, access controls, and non-disclosure.
• Supply Chain Security Policy: Vendor security requirements, component authenticity, and secure logistics.
• IoT Device Policy: Smart factory sensors, connected equipment, and edge computing nodes.

Policy Maturity Model

Figure · Tiers

Maturity levels for policies for information security

Progression Guidance:

• Level 1 → 2: Draft master policy and 5-10 topic policies. Get management approval. Distribute to staff. (Time: 2-4 weeks)
• Level 2 → 3: Expand to full policy suite (20+ policies). Implement formal review cycle. Add acknowledgment tracking. (Time: 1-3 months)
• Level 3 → 4: Add KPIs and metrics. Automate policy distribution and tracking. Quarterly management review. (Time: 3-6 months)
• Level 4 → 5: Implement predictive analytics for policy effectiveness. Integrate with GRC platform. Board-level reporting. (Time: 6-12 months)

More FAQs

Q16: How do we handle policy conflicts between different standards? A: When ISO 27001, PCI DSS, SOC 2, and DPDP Act requirements conflict, create a unified policy that satisfies the most stringent requirement. Document the mapping in a compliance matrix. For specific conflicts, consult legal counsel. Singahi can help develop a unified policy framework that covers multiple standards.

Q17: Should policies be written in plain language or legal language? A: Use plain language for staff-facing policies (they must understand and follow). Use precise legal language for regulatory-facing policies and contracts. Provide both versions when necessary. The policy should be understandable by the person who must follow it.

Q18: How do we manage policies for a global organization with Indian operations? A: Create a global master policy with local annexes. The master policy covers universal requirements (ISO 27001). Local annexes address regional regulations (DPDP Act for India, GDPR for EU). Ensure local policies do not weaken global requirements. Use a policy management platform that supports multi-language and multi-jurisdiction.

Q19: What is the role of the Data Protection Officer (DPO) in policy management? A: Under the DPDP Act 2023, a Data Protection Officer is mandatory only for Significant Data Fiduciaries (s.10); other fiduciaries must publish the contact details of a person who can answer questions (s.8(9)). Where you have a DPO, they are responsible for data protection policies, consent management, breach notification, and regulatory liaison. The DPO must review all policies involving personal data. The DPO reports to the highest management level and has independent authority.

Q20: How do we handle policy management during a merger or acquisition? A: During M&A, conduct a policy gap analysis of the target company. Identify policies that must be harmonized, retired, or created. Integrate target company policies into your framework within 90 days of acquisition. Train acquired staff on new policies. Update risk assessments to reflect the expanded scope.

Illustrative Scenario: Hyderabad SaaS Startup, Policy Failure to Compliance Success

Background

A 50-employee SaaS startup in Hyderabad developed a customer support platform. They had no formal security policies. The founders believed policies were "bureaucratic" and would slow down their agile development process. They had 200+ customers, mostly small businesses in India.

The Incident

In March 2025, a large enterprise customer (a Fortune 500 company) requested a security audit before signing a large annual contract. The audit revealed:

• No information security policy
• No access control policy (developers had admin access to production)
• No incident response policy (a previous minor breach was never documented)
• No data protection policy (customer data was stored unencrypted in some databases)
• No vendor management policy (they used 15+ third-party services with no security assessment)

The customer declined the contract. The startup lost the deal and 3 other enterprise prospects that month, all citing the same security gaps.

Root Cause Analysis

1. No Policy Ownership: No one was responsible for policy development. Security was an afterthought.
2. Founder Mindset: The leadership equated policies with bureaucracy, not understanding that policies enable scalable security and customer trust.
3. No Customer Requirements Analysis: The startup did not realize that enterprise customers require documented security policies as a prerequisite for doing business.
4. Reactive Approach: They only thought about policies when a customer demanded them, not as a proactive business enabler.
5. No Investment in Security: 0% of budget was allocated to security and compliance. The entire security "team" was one developer who handled it part-time.

Remediation

The startup engaged an external security consultant to implement a policy framework:

Phase 1 (Week 1-2):

• Drafted Master Information Security Policy with management commitment
• Developed 8 critical topic policies: Access Control, Data Protection, Incident Response, Vendor Management, Asset Management, Change Management, Acceptable Use, and Cryptographic Controls
• Board approval and publication on internal wiki

Phase 2 (Week 3-4):

• Policy acknowledgment campaign, all 50 employees acknowledged policies within 2 weeks
• Basic training sessions on key policies (Access Control, Data Protection, Acceptable Use)
• Implemented access control changes (role-based access, production access restricted)

Phase 3 (Month 2-3):

• Completed full policy suite (20 policies)
• Implemented incident response procedures with documented playbooks
• Conducted vendor security assessments for all 15+ third-party services
• Deployed encryption for all customer data at rest and in transit

Results:

• Passed a third-party security assessment 4 months later
• Enterprise sales cycle reduced from 6 months to 2 months because security was no longer a blocker
• Achieved ISO 27001 certification 8 months later
• Total Investment: (consulting services + tools). Revenue Impact: s in additional enterprise ARR.

Key Lessons

1. Policies Enable Revenue: Security policies are not overhead, they are a prerequisite for enterprise sales.
2. Start Early: It is easier to build policies when you are 50 people than when you are 500 people.
3. Founder Buy-In is Critical: Security must be championed by leadership, not delegated to IT.
4. Policy Frameworks Scale: A well-designed policy framework scales with the organization. Ad-hoc approaches break down.
5. ROI is Measurable: Quantify the cost of lost deals, extended sales cycles, and customer churn due to security gaps.

Policy Automation and Technology Enablers

Modern policy management uses technology to reduce manual effort and improve compliance. Key enablers include:

Policy Management Platforms:

• ConvergePoint: SharePoint-based policy management with workflows, approvals, and acknowledgment tracking.
• NAVEX One (formerly PolicyTech): GRC platform with policy lifecycle management, version control, and automated distribution.
• PowerDMS: Cloud-based policy management with training integration and compliance tracking.
• SharePoint/Confluence: For smaller organizations, document management platforms with version history and access controls suffice.

Automation Opportunities:

• Automated Distribution: New policy automatically pushed to all relevant staff via email, intranet, or Slack/Teams notification.
• Acknowledgment Tracking: Digital signatures or click-through acknowledgments with automated reminders for non-compliant staff.
• Version Control: Automatic archiving of old versions, with clear change logs highlighting what changed and why.
• Search and Discovery: AI-powered search that helps staff find relevant policy sections quickly.
• Compliance Mapping: Automated mapping of policy clauses to ISO 27001, DPDP Act, RBI, and other requirements.
• Training Integration: Policy changes automatically trigger targeted training modules for affected staff.

Indian Market Solutions:

• Zoho Creator: Low-code platform for building custom policy management workflows (suits smaller organisations).
• Freshservice: ITSM platform with knowledge base and policy distribution features.
• Custom Intranet Solutions: Many Indian organizations build custom policy portals on their existing intranet infrastructure. These offer flexibility and integration with existing sign-on, and suit organisations with in-house development capability.

Indian Regulatory Context for Information Security Policies

Indian organizations must align their information security policies with a layered regulatory environment. The Digital Personal Data Protection Act, 2023 requires policies to cover notice, consent, data principal rights, reasonable security safeguards, breach intimation and grievance redressal. RBI's Cyber Security Framework in Banks and the Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (2023, which replaced the 2017 IT Framework for NBFCs) mandate board-approved cyber security policies, incident reporting within six hours for serious incidents, and periodic independent audits. SEBI's CSCRF (2024) for market infrastructure institutions require complete policies with quarterly reporting. CERT-In directions require organizations to report specified cyber incidents within six hours and maintain ICT asset and user inventories. For SaaS and IT/ITeS companies serving global customers, policies must also address cross-border data transfers under Section 16 of the DPDP Act and customer contractual requirements. We recommend that Indian organizations maintain a single policy repository mapped to ISO 27001, DPDP Act, RBI/SEBI requirements and CERT-In directions, with annual board review and version-controlled approvals.