ISO 27001 A.5.1: Policies for Information Security

Quick Reference: A.5.1 in 60 Seconds

What the Standard Actually Requires

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, have relevant people acknowledge them, and review them on a schedule and after major changes.

ISO 27002:2022 Implementation Guidance (Section 5.1)

ISO 27002 provides 5 implementation guidelines:

1. Policy structure, One master policy + topic-specific policies. Master = high-level direction. Topic-specific = detailed rules.
2. Management approval, Top management must formally approve the master policy. Topic-specific policies approved by appropriate management level.
3. Publication, Policies must be accessible to all relevant personnel. Not hidden in a locked folder.
4. Communication, Policies must be communicated, not just published. Users must know they exist and where to find them.
5. Acknowledgment, Users must formally acknowledge they have read and understood the policies.
6. Review, Review at planned intervals (typically annually) and when significant changes occur.

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 (15-25)                   │
│  • 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                               │
└─────────────────────────────────────────────────────────────┘

The Complete Policy List for ISO 27001:2022

The 25-Policy Framework

Policy Count by Organization Size

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 Objectives
• Protect information assets from all threats, whether internal or external
• Ensure business continuity and minimize business disruption
• Ensure compliance with applicable laws, regulations, and contractual obligations
• Provide a secure environment for all stakeholders
• Continuously 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 
include risk mitigation, risk transfer, risk acceptance, and risk avoidance.

4.3 Risk Acceptance
Risk acceptance decisions are documented and approved by the CISO. 
Accepted risks are monitored and reviewed regularly.

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]
• [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 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
   • Risk acceptance requires CISO approval 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 within 24 hours of termination or role change
   • Password policy: 12+ characters, no forced rotation, breach detection
   • Session timeout: 30 minutes idle for standard, 15 minutes for privileged
4. REVIEW: Quarterly by CISO

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 sensitive roles
   • 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.3 minimum for all 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-2 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 for Critical/High risk require CEO approval)

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 Base 25)

Financial Services Policy Pack (Add to Base 25)

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

Illustrative Scenarios: Policy Failures

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: The Equifax Breach (2017)

What happened: Equifax suffered a breach of 147 million records due to an unpatched Apache Struts vulnerability. The vulnerability was known, but the patch management policy was not followed.

Policy failure:

• Patch management policy existed but was not enforced
• No process for tracking and applying critical patches
• Responsibility for patching was unclear (no policy owner)
• No consequences for non-compliance with patching policy

Lessons for A.5.1:

• Policies must be enforceable, not just documents
• Policy owners must be accountable for compliance
• Policies must include consequences for non-compliance
• Policy effectiveness must be measured and reported

Illustrative Scenario 2: The Capital One Breach (2019)

What happened: A former AWS employee exploited a misconfigured WAF to access 100 million customer records. The cloud security policy was inadequate.

Policy failure:

• Cloud security policy did not cover IAM permissions adequately
• No policy for cloud security posture management
• No policy for regular cloud configuration review
• Supplier security policy did not address cloud provider responsibilities

Lessons for A.5.1:

• Cloud-specific policies are essential for modern organizations
• Policies must evolve with technology
• Supplier security policies must cover cloud shared responsibility
• Policies must be technically specific, not generic

Illustrative Scenario 3: The Twitter Admin Tools Breach (2020)

What happened: Attackers used social engineering to access Twitter's internal admin tools. The access control and incident response policies were insufficient.

Policy failure:

• Access control policy did not require MFA for internal tools
• No policy for social engineering defense
• Incident response policy did not cover insider threats effectively
• No policy for privileged access to internal tools

Lessons for A.5.1:

• Internal tools need the same policy protection as external systems
• Social engineering must be addressed in security policies
• Insider threats must be covered in access control and incident response policies
• Policies must be reviewed after incidents

Multi-Framework Mapping

FAQ

How many policies do we need for ISO 27001?

15-25 topic-specific policies plus the master policy. 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?

Annually at minimum. Additionally, 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 does a full policy suite overhead?

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 (outpatient: 3 years, inpatient: 10 years), 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: 72-hour notification to affected patients and regulatory authorities.

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 policies for Top Secret, Secret, Confidential, and 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 to CERT-In within 6 hours for critical infrastructure.

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

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)

Policy Metrics and KPIs

Additional FAQ

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 DPDP Act 2023, the DPO is 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 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 Singahi 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
• Won the original customer (plus 2 more enterprise deals worth s)
• 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: (Singahi 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 impact 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. Popular in Indian enterprises.
• PolicyTech: Complete 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 (efficient for SMEs).
• 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 solutions offer flexibility, integration with existing authentication systems, and efficientness for organizations with development capabilities and dedicated internal IT support teams across multiple office locations nationwide today globally.

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 IT Framework for NBFCs mandate board-approved cyber security policies, incident reporting within six hours for serious incidents, and periodic independent audits. SEBI's cybersecurity circulars 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. Singahi recommends 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.