ISO 27001 A.5.30: ICT Readiness for Business Continuity

Quick Reference: A.5.30 in 60 Seconds

What the Standard Actually Requires

ISO 27001:2022 A.5.30 Control Text

ISO 27001:2022 Annex A 5.30 asks organizations to plan, implement, maintain, and test ICT readiness so services can be recovered to meet business continuity objectives.

ISO 27002:2022 Implementation Guidance (Section 5.30)

ISO 27002:2022 elaborates that ICT readiness for business continuity is the process of ensuring that information and communication technology services can be recovered within the required timescales defined by the organization's business continuity requirements. The guidance emphasizes:

1. Identification of ICT resources, The organization should identify all information and other resources required to support business continuity plans and procedures. This includes hardware, software, data, networks, cloud services, third-party services, documentation, and personnel.

2. Availability of resources, Once identified, these resources should be made available. This means procuring, configuring, and maintaining redundant capacity, alternate processing sites, backup media, standby systems, and recovery documentation.

3. Readiness for use, Resources must be ready for use when needed. This includes regular testing, exercising, maintenance, and validation of recovery arrangements to ensure they will work during an actual disruption.

4. Alignment with business continuity requirements, ICT readiness should be driven by business impact analysis (BIA) and should support the organization's recovery time objectives (RTO), recovery point objectives (RPO), maximum tolerable downtime (MTD), and service delivery objectives (SDO).

5. Integration with incident management, ICT continuity arrangements should be integrated with information security incident management and crisis management processes.

6. Change management, Changes to ICT infrastructure, applications, or services should be assessed for their impact on ICT readiness and business continuity capabilities.

7. Awareness and training, Personnel involved in ICT continuity should be trained and aware of their roles and responsibilities.

"Shall" vs "Should" Analysis

What Auditors Actually Check

Common Misinterpretations of A.5.30

Why This Control Matters

The Business Risk Narrative

In an era where every business process is digitized, ICT availability is no longer a technical concern, it is a board-level survival issue. A 2024 IBM impact of a Data Breach Report found that the average impact of IT downtime for Indian enterprises ranged from to per hour for large organizations, depending on sector. For a mid-sized Indian SaaS company, even four hours of platform unavailability can trigger customer churn, SLA penalties, and reputational damage that takes quarters to repair.

A.5.30 addresses the readiness dimension: it is not enough to plan for continuity; the ICT resources that make continuity possible must be identified, available, and validated as ready. This control bridges the gap between business continuity theory and operational reality.

Consider what happens when ICT readiness fails:

• A leading Indian bank experienced a 12-hour outage of its core banking system in 2023 because the failover cluster had not been tested after a software patch. Customers could not access accounts, UPI transactions failed, and the bank faced regulatory scrutiny from RBI.
• A Mumbai-based NBFC lost two days of loan processing data because its backup replication to a secondary site had silently failed for six weeks. Recovery required manual intervention over in operational recovery and customer compensation.
• A Bengaluru SaaS unicorn suffered an 8-hour outage when its primary cloud region went down. Although it had a DR site, runbooks were outdated and engineering teams spent four hours just locating current credentials and configuration documentation.

These are not isolated incidents. They are predictable failures of ICT readiness, failures that A.5.30 is specifically designed to prevent.

Indian Regulatory Context

India's regulatory landscape makes ICT readiness a compliance imperative, not merely a best practice.

Digital Personal Data Protection Act, 2023 (DPDP Act)

While the DPDP Act primarily governs personal data protection, its data principal rights and security safeguards imply that organizations must ensure availability of personal data. A breach of availability, such as permanent loss of personal data due to failed backups, can be construed as a compromise of data integrity and security. Penalties under the DPDP Act can reach for serious breaches. ICT readiness directly supports the principle of data security by ensuring personal data remains available and recoverable.

Reserve Bank of India (RBI) Guidelines

RBI's Master Direction on Information Technology Framework for the NBFC Sector, Cyber Security Framework in Banks, and Guidelines on Information Security, Electronic Banking, Technology Risk Management, and Cyber Frauds mandate:

• Business continuity planning and disaster recovery with defined RTO and RPO.
• Annual DR drills, including full-site failover at least once a year for banks.
• Maintenance of a secondary site within India for critical systems.
• Reporting of significant cyber incidents within defined timeframes.
• Board and senior management oversight of cyber resilience.

Non-compliance can result in monetary penalties, restrictions on business operations, and public enforcement actions.

Securities and Exchange Board of India (SEBI)

SEBI's Cybersecurity and Cyber Resilience Framework for Stock Brokers/Depository Participants requires:

• Business continuity and disaster recovery plans.
• Defined RTO and RPO for critical systems.
• Periodic testing and reporting of DR readiness.
• Maintenance of backup sites and redundant infrastructure.

Market infrastructure institutions and intermediaries face strict reporting and audit requirements.

Insurance Regulatory and Development Authority of India (IRDAI)

IRDAI's Guidelines on Information and Cyber Security for Insurers require insurers to implement business continuity and disaster recovery plans, maintain data backups, conduct DR drills, and protect policyholder data availability.

Information Technology Act, 2000

Sections 43, 43A, and 66 of the IT Act 2000 cover compensation for failure to protect sensitive personal data and penalties for unauthorized access, damage to computer systems, and data theft. While not explicitly mandating BCP, the reasonable security practices requirement (Section 43A read with the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011) implies that organizations must maintain safeguards to prevent and recover from disruptions.

CERT-In Directions

The Indian Computer Emergency Response Team (CERT-In) Directions, 2022 require organizations to report cyber incidents within six hours, maintain logs for 180 days, and synchronize ICT system clocks. Effective ICT readiness ensures organizations can respond to, recover from, and report incidents within these windows.

Industry-Specific Consequences

impact of Non-Compliance: Statistics with Indian Context

These figures do not capture the harder-to-quantify overhead: loss of customer trust, employee morale damage, media scrutiny, and opportunity overhead during recovery.

Scope and Applicability

What A.5.30 Covers

A.5.30 covers the identification, availability, and readiness of all ICT resources required by business continuity plans and procedures. This includes:

• Information assets: Databases, files, application data, configuration data, logs, source code, documentation.
• Technology infrastructure: Servers, storage, network devices, firewalls, load balancers, endpoints, OT/ICS systems.
• Software and applications: Business applications, middleware, operating systems, databases, security tools, monitoring tools.
• Networks and connectivity: Internet links, MPLS, SD-WAN, VPN, DNS, CDN, inter-data-centre links.
• Cloud services: IaaS, PaaS, SaaS, container orchestration, serverless functions, cloud databases.
• Third-party and outsourced ICT services: Hosting providers, MSPs, cloud vendors, telecom providers, SOC-as-a-service.
• People and skills: Personnel with continuity roles, on-call rosters, trained recovery teams.
• Documentation and runbooks: BCP, DRP, runbooks, contact lists, architecture diagrams, recovery procedures.
• Physical resources: Alternate sites, backup media, spare hardware, power and cooling.

Who It Applies To

A.5.30 applies across the organization, with specific responsibilities falling to:

Size-Based Applicability

Scenarios Where A.5.30 is Triggered

A.5.30 readiness must be demonstrable for scenarios such as:

• Natural disasters: floods, earthquakes, cyclones, landslides.
• Infrastructure failures: data centre power/cooling failure, hardware failure, storage corruption.
• Cyber incidents: ransomware, destructive malware, supply chain compromise.
• Human error: accidental deletion, misconfiguration, failed change.
• Third-party failures: cloud region outage, ISP failure, MSP collapse.
• Public emergencies: pandemic, civil unrest, terror events, government-mandated shutdowns.
• Cascading failures: a failure in one system triggers downstream outages.

Key Definitions and Terminology

Relationship to Other Controls

A.5.30 does not operate in isolation. It is the organizational hinge that connects business continuity, incident management, backup, redundancy, and change management.

Upstream Controls

Parallel / Integrating Controls

Downstream / Technological Controls

Note: In ISO 27001:2022, "ICT readiness for business continuity" is A.5.30. Older mappings sometimes placed it under A.8.30, but the current standard uses A.5.30.

How the Controls Work Together

Business Impact Analysis (A.5.30 input)
        │
        ▼
Risk Assessment + Asset Management (A.5.12, A.8.1)
        │
        ▼
ICT Continuity Plan + Backup + Redundancy (A.5.30, A.8.13, A.8.14)
        │
        ▼
Incident Detection + Response (A.5.24, A.5.25, A.5.26, A.8.15, A.8.16)
        │
        ▼
Recovery Execution + Crisis Management (A.5.29, A.5.27)
        │
        ▼
Lessons Learned + Continuous Improvement (A.5.27, A.5.35, A.5.36)

Detailed Implementation Guidance

Implementing A.5.30 requires a structured, risk-based approach. The following steps provide a complete implementation pathway, tiered by organization maturity.

Step 1: Establish Governance and Accountability

Before designing technical solutions, define who owns ICT readiness and how decisions are made.

Actions:

1. Appoint an ICT Readiness Owner, typically the CISO or Head of Infrastructure.
2. Form a Business Continuity Steering Committee with representatives from IT, security, operations, legal, HR, facilities, and key business units.
3. Define a charter that includes authority, budget, reporting lines, and escalation paths.
4. Document the ICT readiness policy (template provided in Section 9).
5. Integrate ICT readiness into the ISMS scope statement and management review agenda.

Evidence: Policy document, committee charter, meeting minutes, management review records.

Step 2: Conduct Business Impact Analysis (BIA)

The BIA is the foundation of ICT readiness. Without it, RTO and RPO are guesses.

Actions:

1. Inventory all business processes and ICT services.
2. For each service, identify:
   • Business owner
   • Users and customers affected
   • Financial impact per hour of outage
   • Regulatory and contractual impact
   • Reputational impact
   • Interdependencies with other services
3. Determine Maximum Tolerable Downtime (MTD).
4. Derive Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
5. Classify services as Critical, Important, or Normal.
6. Document dependencies: applications depend on databases; databases depend on storage; storage depends on networks; networks depend on ISPs.
7. Validate BIA with business owners and management.

BIA Classification Table:

Evidence: BIA report, service inventory, RTO/RPO matrix, management sign-off.

Step 3: Identify Required ICT Resources

For each critical ICT service, identify every resource required for recovery.

Actions:

1. Create a Critical ICT Service Register.
2. For each service, document:
   • Application stack (OS, middleware, database, application code)
   • Infrastructure (compute, storage, network)
   • Data stores and data flows
   • Configuration files, secrets, certificates, API keys
   • Third-party dependencies (SaaS, cloud, telecom, MSP)
   • Documentation and runbooks
   • Personnel with recovery skills
   • Physical resources (hardware, alternate site)
3. Map dependencies using a dependency graph or CMDB.
4. Identify single points of failure.

Evidence: Critical ICT Service Register, dependency maps, CMDB extracts.

Step 4: Make Resources Available

Once resources are identified, procure, configure, and maintain them so they are available when needed.

Actions:

1. Backup strategy

   • Implement the 3-2-1-1-0 rule: 3 copies of data, 2 different media, 1 offsite, 1 offline/air-gapped, 0 errors after restore verification.
   • For ransomware resilience, maintain immutable backups.
   • Encrypt backups and secure encryption keys separately.
   • Document backup schedules, retention, and recovery procedures.

2. Redundancy and high availability

   • Deploy clustering, load balancing, and auto-scaling for critical services.
   • Use multi-AZ or multi-region deployments in cloud environments.
   • Maintain redundant network paths and ISPs.
   • Use redundant power (UPS, generator) and cooling.

3. Disaster recovery site

   • Choose an appropriate model: hot site, warm site, cold site, or cloud-based DR.
   • Ensure the DR site is geographically separated from the primary site to avoid correlated risks (e.g., same flood zone, same power grid).
   • For Indian regulated entities, prefer in-country secondary sites where required.

4. Cloud and SaaS continuity

   • Configure cross-region replication.
   • Understand shared responsibility model, cloud provider ensures infrastructure resilience; customer ensures configuration, data, and recovery testing.
   • Maintain vendor continuity clauses and exit strategies.

5. Documentation and runbooks

   • Write step-by-step recovery runbooks.
   • Include contact lists, decision trees, escalation paths, and rollback procedures.
   • Store runbooks in multiple accessible formats (online, offline, printed).

6. Personnel readiness

   • Maintain an on-call roster and succession plan.
   • Train recovery teams and conduct skills assessments.
   • Cross-train personnel to avoid single-person dependency.

Evidence: Backup architecture diagrams, DR site configuration, runbooks, training records, vendor contracts.

Step 5: Ensure Readiness Through Testing

Resources that are not tested are not ready. Testing validates that recovery will actually work.

Types of Tests:

Actions:

1. Develop an annual ICT continuity exercise schedule.
2. Define test objectives, scope, success criteria, and rollback plans.
3. Conduct tests in a controlled manner to avoid production impact.
4. Document results, issues, and remediation actions.
5. Update plans and runbooks based on lessons learned.
6. Report results to management.

Evidence: Exercise plans, test results, issue logs, remediation tracker, management reports.

Step 6: Integrate with Incident and Crisis Management

ICT continuity is not a separate silo. It must be triggered by incident response and crisis management processes.

Actions:

1. Define criteria for invoking ICT continuity plans (e.g., outage exceeding RTO, ransomware, site loss).
2. Align escalation paths between SOC, incident response team, crisis management team, and business continuity team.
3. Include DR invocation steps in incident response playbooks.
4. Ensure communication plans cover internal teams, customers, regulators, vendors, and media.
5. Practice integrated exercises that combine cyber incident response with DR invocation.

Evidence: Incident response playbooks, crisis communication templates, integrated exercise records.

Step 7: Manage Changes and Continuous Improvement

ICT environments change constantly. Every change can affect continuity readiness.

Actions:

1. Include continuity impact assessment in change management.
2. Update BIA and RTO/RPO when business processes change.
3. Review and update ICT continuity plans at least annually.
4. Update runbooks after every test, incident, or major change.
5. Track continuity-related metrics and KPIs.
6. Conduct management reviews of ICT readiness status.

Evidence: Change request records with continuity impact, updated plans, management review minutes.

Implementation by Organization Maturity

Level 1, Reactive

• Maintain basic backups.
• Document a simple recovery procedure.
• Test backup restore at least annually.
• Assign an informal DR owner.

Level 2, Developing

• Conduct BIA for top 10 services.
• Define RTO/RPO.
• Implement offsite backups.
• Create an ICT continuity plan.
• Conduct tabletop exercise annually.

Level 3, Defined

• Complete BIA and service inventory.
• Automated backups with monitoring.
• Warm DR site or cloud multi-region.
• Documented runbooks for critical services.
• Bi-annual exercises including simulation.

Level 4, Managed

• Active-active or near-active DR.
• Automated failover for critical services.
• Integrated incident and crisis management.
• Quarterly exercises.
• Real-time dashboards for RTO/RPO and backup health.

Level 5, Optimizing

• Chaos engineering and continuous resilience testing.
• AI-driven predictive failure analysis.
• Self-healing systems.
• Board-level resilience reporting.
• Continuous improvement culture.

Tools, Technologies, and Solutions

Tool Categories for ICT Readiness

Vendor Comparison Matrix

Indian Vendor Options

Technology Selection Criteria

When selecting ICT readiness tools, evaluate:

1. RTO/RPO support, Can the solution meet your recovery objectives?
2. Scalability, Can it grow with your data and workload volumes?
3. Compatibility, Does it support your OS, applications, databases, and cloud platforms?
4. Security, Does it offer encryption, immutability, RBAC, and audit logging?
5. Ease of recovery, How complex is the restore/failover process?
6. Automation, Does it support automated failover and orchestration?
7. overhead, Include licensing, storage, bandwidth, and operational overhead.
8. Vendor stability, Is the vendor financially stable and compliant with Indian regulations?
9. Support, Is 24/7 support available in India?
10. Integration, Does it integrate with your ITSM, SIEM, and monitoring tools?

Policy and Procedure Templates

ICT Readiness for Business Continuity Policy

ICT READINESS FOR BUSINESS CONTINUITY POLICY
[Organization Name]
Version: 1.0
Approved by: [CEO / Managing Director]
Date: [Date]
Review Date: [Date + 12 months]
Classification: Internal

1. PURPOSE AND SCOPE

1.1 Purpose
This policy establishes the framework for ensuring that information and 
communication technology (ICT) resources required by the organization's 
business continuity plans and procedures are identified, made available, 
and ready for use when needed.

1.2 Scope
This policy applies to all ICT services, systems, data, networks, cloud 
services, third-party ICT providers, and personnel that support the 
organization's critical business processes.

2. POLICY STATEMENT

[Organization Name] is committed to maintaining ICT readiness to ensure 
business continuity during disruptions. The organization shall:

a) Conduct and maintain a Business Impact Analysis (BIA) for all ICT 
   services.
b) Define and document Recovery Time Objectives (RTO), Recovery Point 
   Objectives (RPO), and Maximum Tolerable Downtime (MTD).
c) Identify all ICT resources required to support business continuity.
d) Make those resources available through backup, redundancy, disaster 
   recovery sites, and alternate processing arrangements.
e) Ensure resources are ready for use through regular testing, exercising, 
   and maintenance.
f) Integrate ICT readiness with incident response and crisis management.
g) Review and update ICT continuity arrangements at planned intervals and 
   when significant changes occur.

3. ROLES AND RESPONSIBILITIES

3.1 Board / Top Management
   • Approve the ICT readiness strategy, policy, and budget.
   • Review ICT readiness status at management reviews.
   • Accept residual risks where treatment is not feasible.

3.2 CISO / Information Security Manager
   • Co-own ICT readiness with IT leadership.
   • Ensure security controls are maintained during continuity events.
   • Integrate ICT readiness into the ISMS.

3.3 Head of IT / CTO
   • Own ICT infrastructure recovery.
   • Ensure systems can be restored within defined RTO/RPO.
   • Maintain DR site, backups, and redundancy.

3.4 Business Continuity Manager
   • Coordinate BIA and business requirements.
   • Maintain the business continuity plan and ICT continuity plan.
   • Schedule and facilitate continuity exercises.

3.5 Application Owners
   • Define criticality and recovery requirements for their applications.
   • Participate in BIA and testing.
   • Approve recovery priorities.

3.6 All Employees
   • Follow ICT continuity procedures.
   • Report incidents and disruptions promptly.
   • Participate in training and exercises.

4. BUSINESS IMPACT ANALYSIS

The BIA shall be conducted at least annually and whenever significant 
changes occur. It shall identify:
   • Critical ICT services
   • Dependencies
   • RTO, RPO, and MTD
   • Financial, operational, regulatory, and reputational impacts

5. ICT CONTINUITY ARRANGEMENTS

5.1 Backup
   • Backups shall be performed according to defined schedules.
   • Backup data shall be encrypted, tested, and stored securely offsite 
     or in a separate cloud region.
   • Immutable backups shall be maintained for ransomware protection.

5.2 Redundancy
   • Critical systems shall use clustering, load balancing, or multi-region 
     deployment.
   • Network links shall be redundant where feasible.

5.3 Disaster Recovery Site
   • A DR site or cloud-based recovery environment shall be maintained.
   • The DR site shall be geographically separated from the primary site.

5.4 Third-Party ICT Services
   • Contracts shall include continuity, DR, and incident notification 
     requirements.
   • Key vendors shall provide evidence of their BCP/DR capabilities.

6. TESTING AND EXERCISING

ICT readiness shall be tested through:
   • Quarterly backup restore tests
   • Semi-annual tabletop or simulation exercises
   • Annual full failover tests for critical systems
   • Ad-hoc tests after major changes or incidents

7. CONTINUOUS IMPROVEMENT

Test results, incident reviews, and audit findings shall be used to 
improve ICT readiness. Plans shall be updated accordingly.

8. COMPLIANCE

This policy aligns with ISO 27001:2022 Annex A 5.30, RBI cyber security 
guidelines, SEBI cyber resilience framework, IRDAI guidelines, the DPDP 
Act 2023, and the IT Act 2000.

9. POLICY REVIEW

This policy is reviewed annually and after significant changes.

APPROVED BY:
[CEO Name]                    Date: [Date]
[CISO Name]                   Date: [Date]
[Head of IT Name]             Date: [Date]

ICT Continuity Procedure

PROCEDURE: ICT CONTINUITY ACTIVATION AND RECOVERY
Version: 1.0
Owner: Business Continuity Manager / Head of IT

1. PURPOSE
This procedure describes how to activate and execute ICT continuity 
arrangements during a disruption.

2. SCOPE
Applies to all incidents or disruptions that threaten the availability 
of critical ICT services beyond their defined RTO.

3. ACTIVATION CRITERIA
ICT continuity plans may be activated when:
   • A critical ICT service is unavailable and RTO will be exceeded.
   • A site, region, or major facility is inaccessible.
   • A ransomware or destructive cyber-attack is detected.
   • A natural disaster, fire, or civil emergency affects ICT operations.
   • A third-party service failure impacts critical operations.
   • The Crisis Management Team or CISO declares a crisis.

4. ACTIVATION STEPS

Step 1: Detect and Assess
   • Incident response team or monitoring system detects disruption.
   • Assess impact, affected services, and estimated recovery time.
   • Notify Business Continuity Manager and CISO.

Step 2: Decide on Activation
   • If recovery within RTO is unlikely, recommend activation.
   • Crisis Management Team or authorized owner approves activation.

Step 3: Notify Stakeholders
   • Activate communication tree.
   • Notify internal teams, vendors, customers, and regulators as needed.

Step 4: Execute Recovery
   • Follow runbooks for affected services.
   • Restore from backups, failover to DR site, or activate alternate 
     processing.
   • Verify integrity and security of recovered systems.

Step 5: Resume Operations
   • Validate that services meet acceptance criteria.
   • Gradually restore user access.
   • Monitor for anomalies.

Step 6: Stand Down
   • When primary systems are restored, plan failback.
   • Verify data consistency and system integrity.
   • Return to normal operations.

5. COMMUNICATION
   • Use predefined communication templates.
   • Maintain a call tree and contact list.
   • Designate a single spokesperson for external communication.

6. DOCUMENTATION
   • Maintain an incident log with timestamps and decisions.
   • Record all recovery actions.
   • Capture evidence for post-incident review.

7. POST-EVENT REVIEW
   • Conduct a lessons-learned session within 5 working days.
   • Update BIA, plans, and runbooks as needed.
   • Report to management review.

Risk Assessment and Treatment

Risk Identification

Risk Treatment Plan

Audit and Compliance Checklist

Use this checklist to prepare for internal and certification audits.

Metrics and KPIs

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 Private Sector Bank, Core Banking Failover Failure

Organization: A private sector bank with 1,200+ branches and 15 million customers.

Challenge: In early 2023, the bank experienced a 14-hour outage of its core banking solution (CBS). The primary data centre lost power due to a transformer failure. The uninterruptible power supply (UPS) worked, but the generator failed to auto-start because of a fuel-line issue. When IT attempted to fail over to the secondary data centre, they discovered that the last successful database replication had occurred 36 hours earlier due to a network configuration change that had silently broken replication. The DR site had the application stack but not current data. Recovery required manual database reconstruction from backup tapes, extending the outage.

Impact:

• 14-hour outage of net banking, mobile banking, UPI, and branch operations.
• Estimated revenue impact: .
• RBI issued a show-cause notice and mandated an independent forensic audit.
• Customer complaints flooded social media and banking ombudsman channels.
• Reputational damage took nine months to recover.

Root Causes:

1. Generator maintenance was not tied to business continuity testing.
2. Replication health was not monitored after a network change.
3. DR drills were tabletop-only; no full failover had been attempted in three years.
4. Change management did not assess impact on DR replication.
5. Runbooks did not include verification steps for data currency at DR site.

Solution Implemented (with Singahi's support):

1. Conducted a complete BIA across all 180 ICT services and defined tiered RTO/RPO.
2. Redesigned DR architecture with synchronous replication for Tier 0 and near-synchronous for Tier 1.
3. Implemented automated replication monitoring with alerting.
4. Established quarterly full-site DR drills and monthly backup restore tests.
5. Integrated change management with ICT continuity impact assessment.
6. Created detailed runbooks with decision trees and data-currency checks.
7. Trained 80+ personnel across IT, security, operations, and communications.

Results:

• RTO for Tier 0 services reduced from 14 hours to 45 minutes.
• RPO for Tier 0 services reduced from 36 hours to 5 minutes.
• First successful full-site DR drill completed within 90 days.
• RBI closed the enforcement action after verifying sustained improvement.
• Bank achieved ISO 27001:2022 surveillance audit with zero major nonconformities.

Illustrative Scenario 2: Bengaluru HealthTech SaaS, Ransomware Recovery Through Immutable Backups

Organization: A Bengaluru-based HealthTech SaaS provider serving 400+ hospitals and clinics across India.

Challenge: In late 2023, the company was hit by a ransomware attack that encrypted production servers, databases, and backups stored on a network-attached storage (NAS) device. The attackers had been inside the environment for 21 days before detonating the ransomware. They gained access through a compromised VPN account and moved laterally to the backup server. Because backups were not immutable and were reachable from the production network, they were also encrypted. The company faced a choice: pay the ransom or rebuild from scratch.

Impact:

• 72-hour outage of the patient management platform.
• Potential exposure of 2.8 million patient records.
• Regulatory notification obligations under the IT Act and impending DPDP Act.
• Customer churn of 18% in the following quarter.
• Estimated impact of recovery and business disruption: .

Root Causes:

1. Backups were not air-gapped or immutable.
2. VPN lacked multi-factor authentication (MFA).
3. Lateral movement was not detected due to weak network segmentation.
4. No incident response and DR integration.
5. RTO/RPO were not formally defined; recovery was ad-hoc.

Solution Implemented (with Singahi's support):

1. Deployed immutable backup solution with 30-day object lock and offline/air-gapped copies.
2. Implemented MFA for all remote access and privileged accounts.
3. Segregated networks and restricted backup infrastructure access.
4. Defined RTO (4 hours) and RPO (15 minutes) for the patient platform.
5. Built an automated recovery pipeline that could rebuild the entire environment from immutable backups.
6. Integrated incident response with ICT continuity activation procedures.
7. Conducted quarterly ransomware recovery drills.
8. Implemented 24/7 SOC monitoring and EDR.

Results:

• Successful ransomware recovery drill completed in 3.5 hours (within RTO).
• Data loss limited to 8 minutes (well within RPO).
• Zero ransom paid.
• Regained customer trust; churn stabilized and new customer acquisition resumed.
• Passed a follow-up ISO 27001:2022 certification audit and a customer-led security assessment.

Illustrative Scenario 3: Mumbai NBFC, Cloud Region Outage and Multi-Region Resilience

Organization: A Mumbai-based non-banking financial company (NBFC) with AUM.

Challenge: In 2024, the NBFC's cloud provider experienced a multi-hour outage in the Mumbai region, affecting the NBFC's loan origination system, customer portal, and internal collections platform. Although the cloud provider restored service, the NBFC had no multi-region failover configured. Loan disbursements halted for six hours, and customer service teams were overwhelmed. The outage occurred during a peak festival season, compounding revenue impact.

Impact:

• 6-hour outage affecting 12,000 active loan applications.
• Estimated lost business: .
• Negative media coverage and customer complaints.
• Internal pressure to move away from cloud entirely (which would have been a damaging overreaction).

Root Causes:

1. Single-region cloud deployment.
2. No multi-region DR strategy.
3. Assumption that cloud availability equals application availability.
4. No BIA or formal RTO/RPO for digital lending platforms.

Solution Implemented (with Singahi's support):

1. Conducted BIA for all digital lending and collections platforms.
2. Designed active-passive multi-region architecture with automatic DNS failover.
3. Implemented cross-region database replication with 1-minute RPO.
4. Created runbooks for regional failover and failback.
5. Conducted bi-annual regional failover exercises.
6. Negotiated cloud contract amendments for priority support during outages.

Results:

• RTO reduced to 15 minutes for critical lending platforms.
• RPO reduced to 1 minute.
• Successful regional failover exercise completed within 4 months.
• Management approved resilience budget as a strategic investment.
• Improved customer SLA posture and competitive positioning.

Multi-Framework Mapping

Mapping Notes

• SOC 2 Trust Services Criteria: A.5.30 maps most directly to System Operations (CC7) and Change Management (CC8), with governance linkages to CC1.
• PCI DSS v4.0: Requirement 12.4 covers BC/DR; backup requirements appear in Requirement 12.3.
• NIST 800-53: The Contingency Planning (CP) control family is the primary mapping; Incident Response (IR) and Audit (AU) families are secondary.
• CIS Controls v8: Control 11 (Data Recovery) is the most direct mapping; Controls 4, 7, 8, and 17 provide supporting controls.
• COBIT 2019: A.5.30 spans APO (Align, Plan and Organize), BAI (Build, Acquire and Implement), and DSS (Deliver, Service and Support) domains.
• GDPR / DPDP Act 2023: Both frameworks require appropriate technical and organizational measures to ensure security, including availability and resilience. The DPDP Act's data fiduciary duty reinforces the need for ICT readiness.

Implementation Roadmap

Phase-Based Roadmap

Week-by-Week Plan

Week 1: Governance Kickoff

• Appoint ICT Readiness Owner and steering committee.
• Define scope, objectives, and success criteria.
• Review existing BCP/DR documents.

Week 2: Policy and Planning

• Draft ICT readiness policy.
• Develop project plan and RACI.
• Identify tools and budget.

Week 3: Business Impact Analysis, Part 1

• Inventory business processes and ICT services.
• Interview business owners.
• Draft criticality classification.

Week 4: Business Impact Analysis, Part 2

• Define RTO/RPO/MTD.
• Validate with management.
• Finalize BIA report.

Week 5: Risk and Dependency Assessment

• Map dependencies and single points of failure.
• Update risk register.
• Define treatment plan.

Week 6: Backup Strategy Design

• Design backup architecture (3-2-1-1-0).
• Select backup tools.
• Define retention and encryption.

Week 7: Redundancy and DR Architecture

• Design HA/DR architecture.
• Select DR site or cloud region strategy.
• Define failover mechanisms.

Week 8: Vendor and Third-Party Continuity

• Review critical vendor contracts.
• Issue BCP/DR questionnaires.
• Update contracts with continuity clauses.

Week 9: Documentation Design

• Develop ICT continuity plan template.
• Create runbook templates.
• Design communication templates.

Week 10: Backup Implementation

• Deploy backup solution.
• Configure schedules and retention.
• Set up monitoring and alerting.

Week 11: DR Implementation

• Configure replication/failover.
• Set up DR site or cloud recovery environment.
• Validate network connectivity.

Week 12: Runbooks and Procedures

• Write runbooks for critical services.
• Document activation and recovery procedures.
• Create contact lists and communication trees.

Week 13: Training and Awareness

• Train recovery teams.
• Conduct awareness sessions for all staff.
• Distribute quick reference cards.

Week 14: Initial Testing

• Conduct backup restore tests.
• Perform tabletop exercise.
• Log issues and update plans.

Week 15: Simulation Exercise

• Conduct simulation or partial failover.
• Validate communication and escalation.
• Measure RTO/RPO achievement.

Week 16: Full DR Drill and Closure

• Conduct full failover test (if feasible).
• Conduct post-exercise review.
• Update plans, runbooks, and KPI baselines.
• Present results to management.

Ongoing Activities

FAQ

Q1: Is A.5.30 only for large enterprises? No. A.5.30 applies to all organizations certified to or pursuing ISO 27001:2022. Small organizations can implement pragmatic, cloud-based continuity arrangements.

Q2: What is the difference between A.5.30 and A.5.29? A.5.30 ensures ICT resources are identified, available, and ready for use. A.5.29 focuses on maintaining information security during disruption. They are complementary.

Q3: Do we need a physical DR site, or is cloud DR acceptable? Cloud DR is acceptable if it meets your RTO/RPO and regulatory requirements. Many Indian organizations use cloud multi-region or hybrid DR strategies.

Q4: How often should we test DR? At minimum: annual full failover, semi-annual simulation, quarterly tabletop, and monthly backup restore tests. Regulated industries may require more frequent testing.

Q5: What RTO and RPO should we target? RTO and RPO are business decisions, not IT decisions. They depend on the financial, operational, and regulatory impact of downtime and data loss for each service.

Q6: Is backup alone sufficient for A.5.30? No. Backups are necessary but not sufficient. You also need redundancy, DR capability, tested recovery procedures, trained personnel, and integration with incident management.

Q7: How do we handle ICT readiness for SaaS vendors? Include BCP/DR clauses in contracts, review vendor SOC 2 or ISO 27001 reports, understand their RTO/RPO, and maintain your own data exports where possible.

Q8: What role does the CISO play in A.5.30? The CISO co-owns ICT readiness with IT leadership, ensuring security controls are preserved during failover and recovery, and integrating continuity into the ISMS.

Q9: How do we maintain runbook currency? Update runbooks after every major change, exercise, or incident. Assign owners, schedule periodic reviews, and track currency as a KPI.

Q10: Can we use chaos engineering for A.5.30? Yes. Chaos engineering is an advanced practice that demonstrates and improves resilience. It is most appropriate for mature organizations with strong observability.

Q11: How does A.5.30 relate to RBI cyber security guidelines? RBI guidelines require banks and NBFCs to maintain DR capabilities, define RTO/RPO, conduct drills, and report incidents. A.5.30 provides the ISO framework for meeting these expectations.

Q12: What evidence do auditors typically request for A.5.30? Auditors request BIA, RTO/RPO definitions, ICT continuity plan, backup and restore test records, DR exercise records, vendor contracts, change management records, training records, and management review minutes.

References and Further Reading

Standards and Guidelines

1. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements, Annex A.5.30.
2. ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls, Section 5.30.
3. ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements.
4. ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
5. NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems.
6. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations.
7. CIS Controls v8, Safeguards 11, 17, and related controls.

Indian Regulations

8. Digital Personal Data Protection Act, 2023 (India).
9. Information Technology Act, 2000 (India).
10. Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011.
11. Reserve Bank of India, Master Direction on Information Technology Framework for the NBFC Sector.
12. Reserve Bank of India, Cyber Security Framework in Banks.
13. Reserve Bank of India, Guidelines on Information Security, Electronic Banking, Technology Risk Management, and Cyber Frauds.
14. Securities and Exchange Board of India, Cybersecurity and Cyber Resilience Framework for Stock Brokers/Depository Participants.
15. Insurance Regulatory and Development Authority of India, Guidelines on Information and Cyber Security for Insurers.
16. Indian Computer Emergency Response Team (CERT-In), Directions under Section 70B of the IT Act, 2022.

Industry Reports

17. IBM Security, impact of a Data Breach Report 2024.
18. Uptime Institute, Annual Data Center Survey.
19. Gartner, Market Guide for Disaster Recovery as a Service.
20. Reserve Bank of India annual reports and enforcement actions on IT outages.

Useful Books and Resources

21. Business Continuity and Disaster Recovery Planning for IT Professionals, Second Edition, Susan Snedaker.
22. The Phoenix Project, Gene Kim, Kevin Behr, George Spafford.
23. Chaos Engineering: System Resiliency in Practice, Casey Rosenthal and Nora Jones.
24. NIST Computer Security Resource Center, csrc.nist.gov.
25. ISO Online Browsing Platform, iso.org/obp.

End of guide. This document was prepared by Singahi for ISO 27001:2022 Annex A 5.30, ICT readiness for business continuity. For implementation support, certification guidance, or toolkit customization, contact Singahi at /.