ISO 27001 A.5.29: Information Security during Disruption

Quick Reference (60 Seconds)

What the Control Asks For

The Control in Brief

ISO 27001:2022 Annex A 5.29 asks organizations to plan how to keep information security at an appropriate level during disruption.

Do you need this control?

A.5.29 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. Include it if disruptions (outages, disasters, crises) could weaken security while you recover, which is nearly everyone. Organisations with a mature BCM programme often meet it by adding security requirements to existing continuity plans.

This is a short, deliberately broad statement. It does not limit disruption to earthquakes or fires; it includes any event that prevents the organization from operating in its normal mode. The control obliges the organization to think about information security not only when everything is running smoothly, but also when people are stressed, systems are failing, networks are unreliable, sites are inaccessible, vendors are unavailable, and the pressure to "just get back online" is intense.

ISO 27002:2022 Implementation Guidance (Section 5.29)

ISO 27002 5.29 asks you to determine your requirements for adapting information security controls during disruption, building on the business impact analysis and risk assessment, and to include information security requirements in business continuity management. Plans should be developed, implemented, tested, reviewed and evaluated so that the security of critical business processes is maintained or restored at the required level and within the required time frames. In particular, implement and maintain:

• (a) information security controls, supporting systems and tools within business continuity and ICT continuity plans
• (b) processes to maintain existing controls during disruption
• (c) compensating controls for those that cannot be maintained

27002 also notes that, in the BIA, the consequences of loss of confidentiality and integrity should be considered alongside availability. The practical points below build on this:

1. Integration with business continuity and ICT readiness: Information security during disruption should not be a separate silo. It should be embedded into business continuity plans, disaster recovery plans, ICT readiness for business continuity arrangements, and incident response plans.
2. Risk-based planning: The organization should identify scenarios that could disrupt information security processes and define how security controls will be maintained when those scenarios occur.
3. Process and procedure documentation: Plans should be documented, including roles, responsibilities, escalation paths, communication methods, and decision criteria.
4. Testing and exercising: The organization should test the processes and procedures at planned intervals to ensure they remain effective and familiar to personnel.
5. Review and update: Plans should be reviewed and updated after tests, incidents, significant organizational changes, or changes to the threat landscape.

Shall/Should Analysis

What Auditors Actually Check

Why This Control Matters

The Real-World Risk Narrative

Disruptions do not announce themselves politely. A ransomware attack locks your primary data center on a Friday evening. The Chennai floods make your headquarters inaccessible for a week. A global pandemic forces 80% of your workforce to work from home within 48 hours. A key cloud region in Mumbai experiences an outage during month-end financial closing. A vendor that hosts your identity provider files for bankruptcy without notice.

In each case, the immediate business imperative is to keep operating. But the security imperative does not disappear, it intensifies. Attackers know that organizations are more vulnerable during crises. Phishing emails spike after natural disasters. Ransomware gangs target organizations that are already down. Insider threats increase when oversight mechanisms are relaxed. Regulatory scrutiny intensifies when customer data is exposed because backups were not tested or emergency access was not controlled.

Control A.5.29 exists to ensure that when the organization shifts into crisis mode, information security shifts with it.

Indian Regulatory Context

India's regulatory environment makes A.5.29 especially relevant. Organizations operating in India must consider the following:

Industry-Specific Consequences

Cost of Non-Compliance with Statistics

Research consistently shows that disruptions are expensive, and insecure responses make them worse:

• IBM Cost of a Data Breach Report 2024 found the global average data breach cost reached USD 4.88 million. Breaches where remote work was a factor took longer to identify and contain.
• Downtime costs for Indian BFSI and SaaS organizations can be substantial, depending on size and criticality; estimate yours in the BIA.
• Ransomware incidents in India rose significantly in 2023–2024, with many organizations paying ransoms because backups were either encrypted or untested.
• Regulatory fines under the DPDP Act 2023 can reach INR 250 crore for certain personal data breaches, independent of sector-specific penalties from RBI, SEBI, or IRDAI.
• Customer churn after a breach-related disruption is a major cost; IBM's annual reports consistently list lost business among the largest breach cost components.

A.5.29 is not a "nice to have" continuity add-on. It is a financial, legal, and reputational imperative.

Scope and Applicability

What This Control Covers

A.5.29 covers all processes and procedures required to maintain information security when the organization cannot operate in its normal mode. This includes:

• People security during disruption: Secure remote working, emergency staffing, role changes, temporary workers, contractor surge, fatigue management, insider threat controls.
• Physical security during disruption: Alternate offices, hot desks, recovery sites, home offices, co-working spaces, temporary data centers, equipment movement.
• Technical security during disruption: Failover systems, cloud bursting, backup restoration, break-glass access, emergency privileged accounts, degraded-mode security controls, network reconfiguration.
• Information security during disruption: Data classification handling under stress, secure information sharing, media handling, backup integrity, data leakage prevention.
• Third-party security during disruption: Vendor failover, supplier BCP invocation, cloud provider alternate regions, managed security service continuity, supply-chain security.
• Governance and communication: Crisis decision-making, secure communication channels, regulatory reporting, customer communication, internal escalation.

Who It Applies To

A.5.29 applies to:

• All employees, contractors, interns, and temporary staff.
• All information systems, networks, applications, and data.
• All locations, primary offices, branch offices, data centers, DR sites, cloud regions, home offices, and mobile work environments.
• All third parties that process, store, or transmit the organization's information or provide critical services.
• All business units and functions, including IT, HR, finance, legal, operations, customer support, R&D, sales, and marketing.

Role Categories

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

A.5.29 does not stand alone. It is the security bridge that connects continuity, incident response, access control, backup, redundancy, remote working, and third-party management.

Upstream Controls

Parallel / Integrated Controls

Downstream Controls

Detailed Implementation Guidance

Figure · Matrix

How the options compare: Tabletop exercise to Red team / purple team

A.5.29 implementation can be structured into seven workstreams. Each workstream contains concrete steps, ownership, evidence, and Indian-market considerations.

Workstream 1: Establish Governance and Ownership

Objective: Define who owns information security during disruption and how decisions are made.

Indian context: For RBI-regulated entities, the CMT should include a nodal officer for cyber security as required by the Cyber Security Framework in Banks. SEBI-regulated entities should align the CMT with their cyber crisis management plan structure.

Workstream 2: Identify Disruption Scenarios and Critical Processes

Objective: Understand what could go wrong and which processes must be protected.

Indian scenario examples:

• Monsoon flooding in Mumbai/Chennai makes the primary office inaccessible.
• A cloud provider's Mumbai region experiences a multi-hour outage.
• A ransomware attack encrypts on-premise file servers and backups.
• A pan-India internet outage affects VPN concentrators.
• A pandemic wave forces 100% work-from-home within 24 hours.
• A key SaaS vendor (e.g., email, IAM) suffers a global outage.

Workstream 3: Design Security Controls for Disruption Modes

Objective: Define how each security control adapts during normal, degraded, and emergency modes.

People Security During Disruption

• Awareness refreshers: Conduct annual secure-disruption training and just-in-time reminders when a disruption is declared.
• Home office security: Require secure Wi-Fi, device encryption, screen locks, and a physically private workspace for roles handling confidential data.
• Fatigue and insider threat: Rotate crisis-response staff; monitor for abnormal access; maintain supervision of temporary or surge staff.
• Emergency staffing: Pre-clear background-verified backup personnel for critical roles; document emergency delegation of authority.
• Communication discipline: Use only approved channels for crisis communication; warn staff about phishing and disinformation during crises.

Physical Security During Disruption

• Alternate sites: Pre-approve and assess security of DR sites, branch offices, co-working spaces, and hot desks.
• Equipment movement: Use asset inventory, secure transport, chain-of-custody forms, and encryption for devices moved during disruption.
• Home office: Provide lockable storage, privacy screens, and secure disposal bins for sensitive printouts.
• Visitor control: At alternate sites, maintain visitor logs, badges, and escort requirements even during crisis.

Technical Security During Disruption

• Identity and access: Maintain MFA on all remote access; define break-glass account procedure; ensure identity provider (IdP) has redundancy or offline fallback.
• Network security: Require VPN for all corporate access; have backup internet links (e.g., LTE/5G failover); segment crisis-response networks.
• Endpoint security: Ensure all devices used during disruption have EDR, patching, encryption, and DLP agents.
• Backup and recovery: Maintain offline, immutable, encrypted backups; document restoration procedures; test regularly.
• Monitoring: Define SOC degraded-mode operations; ensure critical alerts still reach on-call staff via redundant channels.
• Cloud resilience: Use multi-region or multi-AZ deployments; document cloud-provider DR procedures; test failover.

Information Handling During Disruption

• Data classification: Reiterate handling rules for confidential/restricted data during crisis; prohibit storage on personal cloud or email.
• Information transfer: Use only approved encrypted channels; avoid USB drives unless authorized and scanned.
• Print and media: Secure printing at alternate sites; shred sensitive documents; label removable media.
• Records retention: Ensure legal hold and regulatory records are preserved despite disruption.

Workstream 4: Document the Information Security During Disruption Procedure

The procedure should be a living document. Key sections include:

1. Purpose and scope
2. Definitions
3. Roles and responsibilities
4. Activation and de-activation criteria
5. Communication plan
6. Secure remote working procedures
7. Alternate site procedures
8. Emergency access and break-glass procedures
9. Backup and restoration procedures
10. Third-party and supplier procedures
11. Evidence preservation and forensic readiness
12. Return-to-normal procedures
13. Post-disruption review
14. Plan maintenance and testing

A template is provided below.

Workstream 5: Test, Exercise, and Validate

Objective: Prove that the plans work before a real disruption occurs.

Testing principles:

• Include security checkpoints in every exercise (e.g., verify MFA still enforced, verify backups are clean, verify logs captured).
• Test out-of-band communication separately from corporate systems.
• Rotate scenarios to cover cyber, natural, health, and supply-chain disruptions.
• Document failures and corrective actions; update the procedure within 30 days.

Workstream 6: Integrate with Incident Response and BCP/DR

A.5.29 should not be a separate document that sits on a shelf. It must be referenced in:

• Incident Response Plan: Include a "disruption declared" branch that invokes A.5.29 procedures.
• Business Continuity Plan: Add security controls to each BCP work area.
• Disaster Recovery Plan: Include security validation steps before failover and before failback.
• ICT Readiness for BC documentation: Align RTO/RPO with security control availability.
• Crisis Communication Plan: Use pre-approved secure templates.

Workstream 7: Maintain and Improve

• Review the A.5.29 procedure at least annually and after any significant change or real disruption.
• Update contact lists, asset inventories, supplier lists, and technology dependencies quarterly.
• Track exercise findings to closure.
• Report A.5.29 status to management review (per Clause 9.3).

Workstream 8: Sector-Specific Considerations for Indian Regulated Entities

Indian regulated sectors have additional expectations that should be embedded into A.5.29 planning from the start, not bolted on after a crisis.

Banking and NBFCs (RBI)

The Reserve Bank of India's Cyber Security Framework in Banks (2016) and the Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (2023), which replaced the 2017 NBFC IT framework, require a Cyber Crisis Management Plan (CCMP), BCP/DR, annual testing, and reporting of unusual cyber incidents. For A.5.29:

• Include a "cyber attack leading to disruption" scenario in the CCMP and A.5.29 procedure.
• Define recovery priorities for critical payment systems, customer channels, and regulatory reporting.
• Maintain a nodal officer for cyber security and alternate contacts for off-hours activation.
• Document how the organization will continue regulatory reporting (e.g., RBI returns, NEFT/RTGS/UPI reconciliation) securely during disruption.
• Test failover to the alternate data center or cloud DR region at least annually and include security validation.
• Preserve transaction logs and audit trails for RBI inspection even when operating in degraded mode.

Securities Market (SEBI)

SEBI's CSCRF (2024) applies to market infrastructure institutions, stock brokers, depository participants, asset management companies, and others. Key A.5.29 implications:

• Ensure trading continuity and investor data protection during disruption.
• Pre-approve secure communication channels for market operations and investor grievance handling.
• Maintain immutable logs of trading activity and system access.
• Define how to notify SEBI, stock exchanges, and depositories of cyber incidents that disrupt market operations.
• Conduct annual cyber resilience testing including scenarios that combine cyber attack with infrastructure failure.

Insurance (IRDAI)

IRDAI's information and cyber security guidelines require insurers to protect policyholder data, maintain BCP, and report cyber incidents. For A.5.29:

• Prioritize continuity of policy issuance, claims processing, and regulatory filings.
• Ensure agent and intermediary portals remain secure during disruption.
• Define secure handling of policyholder personal data when staff work remotely.
• Align incident notification with IRDAI's reporting requirements.

All Sectors (CERT-In and DPDP Act 2023)

• Any cyber incident reportable to CERT-In must be reported within 6 hours of noticing or being notified of the incident. A.5.29 activation should not delay this.
• Personal data breaches under the DPDP Act 2023 require notification to the Data Protection Board and affected data principals. The communication plan must include legal review and secure notification methods.
• Maintain logs for 180 days and synchronize clocks per CERT-In Directions; disruption plans must not lose this capability.

Startups and Non-Regulated Tech Companies

Even without sector regulators, these organizations face contractual SLA and customer trust pressures. A.5.29 should focus on:

• Cloud-native resilience (multi-AZ, multi-region).
• Fast, secure WFH enablement.
• Transparent customer communication during outages.
• Demonstrable backup and recovery for SOC 2 and enterprise customer audits.

Tools, Technologies, and Solutions

The following tools support A.5.29 implementation. Selection should be based on organization size, risk profile, and budget.

Category: Business Continuity and Incident Management

Category: Secure Remote Working and Identity

Category: Communication and Collaboration

Category: Monitoring and Forensics

Selection Guidance

• Startups and SMEs: Use cloud-native services (Microsoft 365 / Google Workspace), Duo MFA, cloud backup (Druva / Veeam), and free/lightweight tabletop exercises.
• Growing companies: Add a dedicated BC/DR tool, SIEM, managed SOC, and structured crisis communication platform.
• Enterprise / Regulated: Implement integrated GRC/BC platforms, immutable backup with air-gapping, multi-region cloud architecture, and regular red-team exercises.

Policy and Procedure Templates

Template 1: Information Security During Disruption Policy

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

---

1. PURPOSE AND SCOPE

1.1 Purpose
This policy establishes the requirements for maintaining information security 
when normal business operations are disrupted by incidents such as cyber 
attacks, natural disasters, pandemics, infrastructure failures, supply-chain 
failures, civil unrest, or any other event that prevents the organization from 
operating in its normal mode.

1.2 Scope
This policy applies to all employees, contractors, temporary staff, vendors, 
and third parties who access, process, store, or transmit [Organization Name] 
information assets during a disruption. It covers all locations, systems, 
networks, applications, and data.

2. POLICY STATEMENT

[Organization Name] is committed to protecting the confidentiality, integrity, 
and availability of its information assets at all times, including during 
disruptions. The organization shall plan, document, test, and maintain 
processes and procedures for information security during disruption.

3. ROLES AND RESPONSIBILITIES

3.1 Top Management
• Approve this policy and the resources required for its implementation.
• Receive briefings from the Crisis Management Team during significant 
  disruptions.
• Support a culture where security is not sacrificed for speed during crisis.

3.2 Chief Information Security Officer (CISO)
• Own this policy and the associated procedure.
• Ensure integration of information security into BCP, DR, and incident 
  response plans.
• Plan and oversee exercises to validate security during disruption.

3.3 Business Continuity Manager
• Maintain BCP/DR plans with embedded security requirements.
• Coordinate Business Impact Analysis and disruption scenario planning.
• Track exercise findings to closure.

3.4 CIO / IT Director
• Ensure ICT readiness, backup, redundancy, failover, and emergency access.
• Maintain technical playbooks for secure failover and failback.

3.5 Crisis Management Team
• Activate and manage the organization's response to disruption.
• Make security-aware decisions and escalate where required.

3.6 All Employees
• Comply with secure remote working, alternate-site, and emergency 
  procedures during disruption.
• Report security incidents, suspicious activity, or policy violations 
  immediately.

4. KEY REQUIREMENTS

4.1 Planning
• A documented Information Security During Disruption procedure shall be 
  maintained.
• Disruption scenarios shall be identified and risk-assessed.
• Critical processes, systems, and data shall have defined RTO, RPO, and 
  minimum security controls for degraded operation.

4.2 Activation
• Disruption shall be declared by authorized personnel per the escalation 
  matrix.
• The Crisis Management Team shall convene within [15 minutes / 1 hour] of 
  activation.
• Secure communication channels shall be used for all crisis coordination.

4.3 Secure Remote and Alternate-Site Working
• MFA shall be enforced for all remote access.
• Only organization-managed or approved devices shall access corporate 
  information.
• Sensitive information shall not be stored, printed, or discussed in 
  insecure locations.

4.4 Emergency Access
• Break-glass and emergency privileged access shall be pre-authorized, 
  logged, time-bound, and revoked immediately after use.
• Emergency access shall require approval from the CISO or designated deputy.

4.5 Backup and Recovery
• Backups shall be encrypted, immutable, tested, and stored separately from 
  primary systems.
• Restoration shall follow documented procedures and include security 
  validation before returning to production.

4.6 Third Parties
• Critical suppliers shall have documented BCP/DR plans and security 
  commitments.
• Supplier failover procedures shall be tested annually.

4.7 Communication
• Pre-approved crisis communication templates shall be used.
• Internal and external stakeholders shall be informed through secure, 
  authorized channels.
• Regulatory notifications (e.g., CERT-In, RBI, SEBI, IRDAI, DPDP Act) shall 
  be made within mandated timeframes.

4.8 Return to Normal
• A structured return-to-normal plan shall ensure systems, networks, and 
  processes are restored securely.
• Evidence preservation and forensic requirements shall be met before 
  rebuilding affected systems.

4.9 Testing and Review
• The procedure shall be tested at least annually through tabletop, 
  functional, or full-scale exercises.
• The policy and procedure shall be reviewed annually and after any 
  significant disruption, change, or exercise finding.

5. COMPLIANCE

Non-compliance with this policy may result in disciplinary action, including 
termination, and may expose the organization to legal, regulatory, and 
contractual liability.

6. REVIEW AND APPROVAL

This policy is reviewed annually. Changes are approved by top management.

APPROVED BY:
[Name]                    [Title]                    [Date]

Template 2: Information Security During Disruption Procedure

INFORMATION SECURITY DURING DISRUPTION PROCEDURE
[Organization Name]
Version: 1.0
Owner: CISO / Business Continuity Manager

1. ACTIVATION

1.1 Activation Triggers
Activation occurs when any of the following affect critical operations:
• Ransomware or significant cyber attack
• Natural disaster (flood, earthquake, cyclone, fire)
• Pandemic or health emergency
• Primary office or data center inaccessible
• Critical cloud/service provider outage
• Major supply-chain failure
• Civil unrest or government-imposed restrictions
• Any event where the Crisis Management Team determines that normal 
  operating mode cannot maintain information security

1.2 Activation Authority
Primary: CISO or CEO
Deputy: Business Continuity Manager or CIO

1.3 Activation Steps
1. Declare disruption via approved communication channel.
2. Convene Crisis Management Team.
3. Notify relevant regulators if required (CERT-In within 6 hours for cyber 
   incidents; RBI/SEBI/IRDAI per sector timelines; DPDP Act for personal 
   data breaches).
4. Activate secure communication channel.
5. Invoke BCP/DR and A.5.29 security procedures.

2. SECURE COMMUNICATION

• Use [out-of-band channel, e.g., WhatsApp Business group, SMS gateway, 
  Everbridge] if corporate email/Teams is unavailable.
• Authenticate all participants using a pre-agreed code word or second 
  factor before sharing sensitive information.
• Do not discuss confidential matters on unapproved social media or public 
  channels.

3. SECURE REMOTE / ALTERNATE-SITE OPERATIONS

3.1 Remote Working
• Employees must use organization-managed devices with EDR, encryption, 
  and patched OS.
• Connect only via VPN or approved Zero Trust access.
• Home Wi-Fi must use WPA2/WPA3 and a strong passphrase; avoid public Wi-Fi 
  for confidential work.
• Maintain physical privacy; lock screens when away.

3.2 Alternate Site
• Verify site access control, CCTV, network segmentation, and visitor 
  management before occupation.
• Issue temporary badges; maintain visitor log.
• Scan all devices connecting to the alternate-site network.
• Use locked storage for sensitive documents and equipment.

4. EMERGENCY ACCESS AND BREAK-GLASS

4.1 Request
• Requestor submits emergency access form with business justification, 
  systems required, and duration.
• Approval required from CISO or designated deputy.

4.2 Grant
• Enable time-limited break-glass account or temporary privilege escalation.
• Log all actions; monitor session in real time if possible.

4.3 Revocation
• Revoke access immediately upon completion or expiry.
• Review logs within 24 hours; document any anomalies.

5. BACKUP AND RECOVERY

5.1 Before Restoration
• Verify backup integrity and malware scan results.
• Confirm restoration target environment is clean and patched.
• Preserve forensic evidence where investigation is ongoing.

5.2 During Restoration
• Follow documented RTO/RPO targets.
• Validate data integrity and access controls before releasing systems to 
  users.

5.3 After Restoration
• Re-enable monitoring, logging, and alerting.
• Conduct security validation tests.

6. THIRD-PARTY COORDINATION

• Contact critical suppliers via pre-defined escalation paths.
• Confirm supplier recovery status and security posture before re-establishing 
  integrations.
• Document any supplier security exceptions with risk acceptance.

7. RETURN TO NORMAL

7.1 Return Criteria
• Primary systems and sites are restored and validated.
• Security controls are operating at normal levels.
• Regulatory and legal obligations are met.
• CMT approves return-to-normal.

7.2 Return Steps
1. Migrate users from alternate sites / remote crisis mode to normal mode.
2. Revoke all emergency access and temporary privileges.
3. Collect and securely destroy any sensitive documents or media from 
   alternate sites.
4. Reconcile asset inventory and access rights.
5. Conduct post-disruption review.

8. POST-DISRUPTION REVIEW

Within [5 / 10 / 15] business days:
• Document timeline, decisions, and security incidents.
• Identify lessons learned and root causes.
• Update BCP/DR, incident response, and A.5.29 procedure.
• Close corrective actions.
• Report to management review.

Risk Assessment and Treatment

A.5.29 planning must be grounded in risk assessment. The following table provides a starting risk register for information security during disruption. Organizations should adapt likelihood and impact ratings based on their specific threat landscape, location, and industry.

Risk Register: Information Security During Disruption

Treatment Options

Audit and Compliance Checklist

Use the following 25 questions to prepare for internal and external audits of A.5.29.

Metrics and KPIs

Track the following metrics to demonstrate A.5.29 effectiveness and drive continuous improvement.

Common Pitfalls / Audit Failures & How to Avoid Them

Illustrative Scenarios

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

Illustrative Scenario 1: Indian SaaS Startup, Ransomware Disruption and Secure Recovery

Organization: A Bengaluru-based B2B SaaS company with 120 employees serving 400 enterprise customers in India and Southeast Asia.

Challenge: On a Sunday evening, a ransomware group deployed a locker across the company's primary AWS VPC and on-premise file server. The attackers also deleted visible snapshots. The company discovered the issue Monday morning when customer support tickets began reporting service unavailability. The incident threatened customer data, SLA commitments, and an upcoming ISO 27001 Stage 2 audit.

What Went Wrong Initially:

• The company had backups but had not tested restoration in six months.
• The disaster recovery plan did not include a security validation step before failback.
• Several engineers shared a break-glass AWS root account password via a group chat to "fix things quickly."
• The crisis communication plan relied on the same Microsoft 365 tenant that was partially affected.
• There was no predefined procedure for notifying CERT-In or customers under the DPDP Act 2023 framework.

Solution Implemented with external support:

• Activated the incident response plan and declared a disruption under A.5.29.
• Isolated affected environments and preserved forensic evidence before any recovery.
• Identified immutable backups in a separate AWS account that had not been compromised.
• Restored critical services to a clean, hardened environment in a different AWS region.
• Replaced shared break-glass credentials with individual, time-bound, MFA-protected emergency access with full CloudTrail logging.
• Used an out-of-band WhatsApp Business group and SMS alerts for crisis communication.
• Engaged legal counsel to assess CERT-In, customer contract, and DPDP Act notification obligations.
• Conducted a post-incident review and updated BCP, DR, IR, and A.5.29 procedures.

Results:

• Critical services restored within 36 hours; full restoration completed in 72 hours.
• Zero customer data exfiltration confirmed through forensic analysis.
• Passed the ISO 27001 Stage 2 audit four weeks later with only one minor observation.
• Customer churn limited to two accounts; most customers appreciated transparent communication.
• Implemented quarterly backup restore tests and bi-annual ransomware recovery drills.

Lessons Learned:

• Backups are only as good as the last successful restore test.
• Shared emergency credentials create more risk than the incident itself.
• A.5.29 must be integrated with IR, BCP, DR, and regulatory notification workflows.
• Out-of-band communication is essential when primary systems are suspect.

Illustrative Scenario 2: Indian NBFC, Flooding, WFH Surge, and Regulatory Continuity

Organization: A mid-sized Non-Banking Financial Company (NBFC) headquartered in Chennai with 18 branches across South India and 850 employees.

Challenge: Severe flooding in Chennai made the head office and primary data center inaccessible for nine days. Simultaneously, the RBI issued a directive requiring regulated entities to maintain critical financial operations with no degradation in security controls. The NBFC had to shift nearly 70% of operations to remote work within 24 hours while ensuring loan processing, payments, and customer data remained protected.

What Worked:

• A BCP existed and alternate sites had been pre-identified.
• Core banking systems were hosted in a Mumbai data center with redundancy.
• VPN infrastructure was already in place for some users.

What Did Not Work:

• VPN licenses covered only 30% of the workforce.
• There was no secure WFH procedure for customer-facing roles handling PAN, Aadhaar, and bank account data.
• Branch staff began using personal email and WhatsApp to share loan documents.
• The BCP did not address how to verify identity and authorize transactions when staff were dispersed.
• Backup power at the alternate site was insufficient for full operations.

Solution Implemented with external support:

• Declared a disruption and activated the Crisis Management Team.
• Procured additional VPN/Zero Trust licenses and enforced MFA for all remote access.
• Issued a secure WFH directive prohibiting personal email/USB for customer data and mandating privacy screens and encrypted devices.
• Deployed a virtual desktop infrastructure (VDI) for customer-facing roles so data never resided on personal devices.
• Implemented daily transaction reconciliation and dual authorization for high-value disbursements.
• Established a secure file-sharing portal with DLP to replace informal channels.
• Coordinated with the Mumbai data center and cloud DR provider to validate failover.
• Updated RBI reporting with timely incident and continuity-status notifications.

Results:

• Loan disbursements resumed at 85% capacity within 48 hours.
• No reportable data breach occurred during the disruption.
• RBI inspection six months later commended the NBFC's cyber crisis management and secure continuity posture.
• The organization achieved a mature A.5.29 implementation and reduced its cyber insurance premium by 12%.
• Post-event, the NBFC adopted a permanent hybrid work model with security controls that exceeded pre-flood levels.

Lessons Learned:

• WFH capacity must be planned for the entire workforce, not a subset.
• Customer-facing financial processes need stronger controls during disruption than back-office processes.
• Informal communication channels become the default in a crisis unless secure alternatives are ready.
• Sector-specific regulatory expectations (RBI) must be hard-wired into A.5.29 procedures.

Multi-Framework Mapping

A.5.29 aligns with multiple global and Indian frameworks. Use this table to demonstrate cross-framework compliance and avoid duplicate work.

Implementation Roadmap

The following 12-week roadmap takes an organization from initial planning to an audit-ready A.5.29 implementation.

Phase 1: Foundation (Weeks 1–2)

Phase 2: Planning and Documentation (Weeks 3–5)

Phase 3: Technical and Operational Readiness (Weeks 6–8)

Phase 4: Testing and Training (Weeks 9–10)

Phase 5: Review and Audit Preparation (Weeks 11–12)

Ongoing Activities

• Quarterly contact-list and asset-inventory updates.
• Semi-annual tabletop exercises.
• Annual full-scale exercise or supplier resilience test.
• Annual policy/procedure review or review after significant change/incident.

FAQ

Q1: Is A.5.29 the same as business continuity planning?

No. Business continuity planning focuses on keeping the business running. A.5.29 focuses specifically on maintaining information security while the business is operating in disruption mode. The two must be integrated, but A.5.29 adds the security lens.

Q2: Do small organizations need a full A.5.29 procedure?

Yes, but proportionally. A 20-person startup can have a concise checklist, cloud backups, MFA, and a quarterly tabletop exercise. A 2,000-person bank needs a complete, tested program. The standard expects planning appropriate to the organization's context and risk.

Q3: What counts as a "disruption" for A.5.29?

Any event that prevents normal operation and requires alternate working methods. Examples include ransomware, floods, fires, pandemics, power failures, internet outages, civil unrest, supply-chain failures, and major cloud provider outages.

Q4: How often should we test A.5.29 plans?

At minimum, annually. Best practice includes a semi-annual tabletop exercise, an annual functional or full-scale exercise, and quarterly backup restore tests. Test after significant changes as well.

Q5: Should A.5.29 be a separate document or part of the BCP?

It can be a standalone procedure that references the BCP, or a dedicated section within the BCP. The key requirement is that information-security-during-disruption is explicitly planned, documented, tested, and maintained.

Q6: How do we handle emergency access during a disruption without creating audit failures?

Use pre-defined break-glass accounts, require approval from a designated authority, enforce MFA, limit duration, log all activity, and conduct a post-use review within 24 hours. Never share passwords.

Q7: What if our cloud provider fails, does A.5.29 apply?

Yes. A.5.29 requires planning for any disruption, including cloud or SaaS provider outages. This includes multi-region deployment, backup providers, alternate communication channels, and supplier failover testing.

Q8: How does A.5.29 relate to COVID-19-style work-from-home mandates?

A.5.29 is exactly the kind of control that should have guided secure WFH during the pandemic. Organizations that had planned for secure remote operation could scale it with fewer emergency exceptions.

Q9: What regulatory notifications are required during a disruption in India?

It depends on the cause. Cyber incidents must be reported to CERT-In within 6 hours. Personal data breaches may require notification under the DPDP Act 2023. RBI, SEBI, and IRDAI have sector-specific timelines. Include these in your A.5.29 communication plan.

Q10: Can A.5.29 help reduce cyber insurance premiums?

Yes. Insurers increasingly look for evidence of resilience, backup testing, incident response readiness, and business continuity. A strong A.5.29 program can positively influence underwriting.

References and Further Reading

Standards and Frameworks

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements.
• ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls.
• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements.
• ISO/IEC 27031:2025, ICT readiness for business continuity (replaced the 2011 edition).
• ISO 22313:2020, Business continuity management systems, Guidance on the use of ISO 22301.
• ISO/IEC 27035 series, Information security incident management.
• ISO/TS 22317:2021, Guidelines for business impact analysis.
• NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations.
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems.
• CIS Controls v8, Center for Internet Security.
• COBIT 2019, ISACA.

Indian Regulations and Guidelines

• Digital Personal Data Protection Act, 2023 (India).
• Information Technology Act, 2000 (as amended).
• CERT-In Directions, 2022 (Information Security Practices, Procedure, Prevention, Response and Reporting of Cyber Incidents for Safe & Trusted Internet).
• Reserve Bank of India, Master Direction on Information Technology Framework for the NBFC Sector; Cyber Security Framework in Banks.
• Securities and Exchange Board of India, Cyber Security and Cyber Resilience framework for MIIs, stock brokers, depository participants, etc.
• Insurance Regulatory and Development Authority of India, Guidelines on Information and Cyber Security for Insurers.

Useful Resources

• RBI Cyber Security Framework for Banks: https://www.rbi.org.in
• SEBI CSCRF (20 August 2024): https://www.sebi.gov.in
• CERT-In: https://www.cert-in.org.in
• MeitY, DPDP Act 2023: https://www.meity.gov.in
• ISO 27001:2022 Annex A control mapping resources.
• Singahi ISO 27001 Blog and Resources: /

End of guide.