ISO 22301 Clause 7.5: Documented Information

Quick Reference (60 Seconds)

If you only read one thing: Clause 7.5 is where the BCMS is treated as a durable, regulated, evidence-bearing system rather than a pile of files. A 7.5-conformant BCMS is one in which the organisation has decided, in writing, what documented information the BCMS needs, created it with the right identification, format and approval, kept it current through versioned change control, made it available where and when it is needed (including during the disruption it is designed to manage), protected it from loss and tampering, retained it for every regulatory clock that applies, and disposed of it securely at end-of-life. The certification auditor will examine this discipline ruthlessly, and so will a regulator after a disruption, when a BCMS fails, the third question after "what happened?" and "who knew?" is always "where is the record, is it current, is it retrievable, and is it the version that was in force on the day?". Get 7.5 wrong and however strong the policy, the BIA and the plans, the BCMS will fail on the day it is activated because the plans the response depends on will be on the system that is down, the contact tree will be the version from last quarter, the retention clock will be unmet, and the audit evidence will be irretrievable. Get it right and the BCMS becomes a system whose evidence is as resilient as its operations, available, current, protected and provable, on the worst day and on every ordinary day.

What the Standard Actually Requires

The paraphrased requirement

ISO 22301 Clause 7.5 asks organizations to create, update, and control the documented information the BCMS requires. The clause sits inside Clause 7 (Support) and forms the evidence and memory layer of the BCMS. Three obligations flow from the paraphrase, each of which an auditor will test independently, and the clause is structured into three sub-parts that operationalise them.

Obligation 1, Create (sub-part 7.5.1, General). The organisation must determine what documented information the BCMS needs. ISO 22301:2019 explicitly requires the BCMS to retain certain documented information, the scope (Clause 4.3), the BC policy (Clause 5.2), the BC objectives and plans to achieve them (Clause 6.2), the evidence of competence (Clause 7.2), the evidence of communication (Clause 7.4), the BIA and risk assessment (Clause 8.2), the continuity strategies and solutions (Clause 8.3), the BC plans and procedures (Clause 8.4), the exercise programme and its results (Clause 8.5), the evaluation of documentation and capabilities (Clause 8.6), the monitoring and measurement results (Clause 9.1), the internal audit programme and results (Clause 9.2), the management review results (Clause 9.3), and the nonconformity and corrective-action records (Clause 10.1). Beyond these explicit items, the organisation must also determine any additional documented information it needs to demonstrate the effective operation of the BCMS, the "additional" category is where most Indian growing companies under-shoot, because the explicit list is a floor, not a ceiling. The "create" obligation also implies that the organisation must decide what is not documented information, over-documentation is a recognised anti-pattern, and the clause does not require a document for every passing thought. The test an auditor applies is necessity: is this documented information needed for the BCMS to function, to be audited, or to be improved?

Obligation 2, Update (sub-part 7.5.2, Creating and updating). When documented information is created or updated, the organisation must ensure it has appropriate identification and description, title, date, author, reference number, version, so that any reader can tell what the document is, when it was issued, who issued it and which version is in force. The organisation must also ensure the documented information is in a suitable format and on suitable media, electronic, paper or hybrid, in a file format that remains readable over the retention period, on a medium that survives the disruption the document is designed to support. And the organisation must ensure appropriate review and approval for suitability and adequacy, a controlled document is not "published" until a named approver has reviewed it for suitability (does it fit the purpose) and adequacy (is it complete and correct). The "update" obligation is not a one-time event; it is a continuing duty to keep the documented information current, which means a defined review cadence (annual, on trigger, on regulatory change, on organisational change, on post-disruption review) and a controlled change process that versions every change.

Obligation 3, Control (sub-part 7.5.3, Control of documented information). The documented information the BCMS depends on, and what ISO 22301 itself calls for, must be controlled so that it is on hand wherever and whenever someone needs it, in a form they can actually use. It must be adequately protected, from loss of confidentiality, integrity, availability and improper use. Distribution, access, retrieval and use must be controlled. It must be stored and preserved in a way that keeps it readable and usable throughout its retention period, including the control of external-origin documents whose distribution and updating the organisation must manage. And retention and disposition must be managed, the organisation must decide how long each record class is kept and how it is disposed of at end-of-life, with disposal evidenced. The "control" obligation is the densest of the three because it covers the full lifecycle of the document after it is published, and because it is where the Indian regulatory clocks bite hardest, the CERT-In 180-day log retention and 5-year KYC rules, the IRDAI 180-day log rule, the DPDP erasure duty, the Companies Act 8-year book retention, the RBI and SEBI record-retention expectations.

What the standard does NOT require (the demarcation competitors miss)

Clause 7.5 is often conflated with neighbouring clauses and with broader information-management disciplines. It is helpful to be explicit about what is out of scope for 7.5 itself, because auditors test the boundary:

• It does not require the BCMS to be over-documented. The clause requires the documented information the BCMS needs, not every conceivable document. A common anti-pattern is the "documentation mountain" where a growing company produces a hundred-page BC plan no one reads, a BIA that documents every process to the same depth, and a set of procedures that duplicate the work instructions. The clause requires adequacy, not volume; an auditor will flag over-documentation as readily as under-documentation, because over-documentation is itself an adequacy failure (the documents are not suitable for use if no one can find or read them).
• It does not require a specific technology. The clause is outcome-based: documented information must be controlled. A document-management system, an enterprise GRC platform, a records-management suite, a version-control repository, a quality-management system, a collaboration platform with versioning, or even a well-disciplined shared drive with a controlled naming convention and a change log can all satisfy the requirement at appropriate scale. An auditor who insists on a particular product is over-specifying; the right test is "is the document controlled, version-current, access-managed, retrievable, protected and retained". The choice of technology is a Clause 7.1 resourcing decision.
• It does not require all documented information to be electronic. Paper, hybrid and electronic formats are all valid where suitable. For an Indian manufacturing site with a shop-floor workforce, a printed and signed emergency-evacuation procedure posted at the assembly line may be more suitable than an electronic document on a portal no one on the floor can access. The "suitable format and media" decision is per document class, not enterprise-wide.
• It does not require records to be kept forever. The clause requires retention and disposition to be managed, which includes disposal. A "keep everything forever" regime is non-conformant because it is not a management decision; it is the absence of one. The retention schedule must define a retention period for each record class, and disposal must be executed and evidenced.
• It does not require the documented information itself to be correct in substance. This is subtle. The clause requires the documented information to be suitable and adequate, reviewed and approved, but whether the BIA's RTO figure is the right figure is a Clause 8.2 question. 7.5 asks "is the BIA a controlled document, current, approved, retrievable"; 8.2 asks "is the BIA correct". A BCMS can be 7.5-conformant and still have a wrong RTO; what it cannot be is 7.5-conformant without a controlled BIA at all.
• It does not require personal data to be protected. That is partly Clause 7.5 (protection) and partly the information-security controls (ISO 27001 Annex A, the organisation's ISMS). Where documented information contains personal data, the DPDP Act 2023 applies on top, but that is a regulatory duty, not a 7.5 duty per se. 7.5 requires protection of documented information; the DPDP defines what "protection" means for personal data.
• It does not require the organisation to author the standards it references. External-origin documents, ISO standards, regulator circulars, supplier contracts, certificates, are within scope of 7.5 control (distribution and updating must be managed), but the organisation does not author them. The External-Origin Document Register is the control artefact.

The companion guidance and adjacent standards

The clause text is short; the method lives in companion and adjacent standards. Both are paywalled; cite the current edition:

• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301. The clause-by-clause companion. Use it as the authoritative explanation of what 7.5 evidence should look like and how documented information interlocks with the rest of the BCMS.
• ISO/IEC 27001:2022 Clause 7.5, the Information Security Management System analogue, with the same Harmonized Structure. Useful for integrated audits and for evidencing documented information control across the ISO 27001 / 22301 stack. The control statements are structurally identical at the clause level; the difference is in the kinds of documented information each system prioritises.
• ISO/IEC 27001:2022 Annex A control 5.29 (information security during disruption), 5.30 (ICT readiness for business continuity), 8.13 (information backup, directly relevant to the protection of documented information), 8.14 (redundancy of information processing, relevant for document availability), 5.33 (physical and environmental security, relevant for paper-document protection), 5.12 (classification of information, relevant for the protection regime), 5.34 (privacy and protection of personal data, relevant where records contain personal data), 8.10 (information deletion, directly relevant to retention and disposal). The 27001 / 22301 overlap is densest here.
• ISO/IEC 27031:2011, Guidelines for information and communication technology readiness for business continuity. Somewhat dated but still the canonical reference for ICT readiness, including the readiness of the document-management infrastructure itself.
• ISO 15489-1:2016, Information and documentation, Records management. The canonical records-management standard. Not BCM-specific, but the recognised source for the records lifecycle (create, capture, classify, store, access, use, retain, dispose) that 7.5's control regime operationalises.
• ISO 9001:2015 Clause 7.5, "Documented Information" in the Quality Management System. Useful where the organisation has an integrated QMS/BCMS, especially for the document-control discipline.
• ISO 22300:2021, Security and resilience, Vocabulary. The normative source for definitions of document, record, documented information, version, retention, disposition. A fourth edition (ISO/DIS 22300) is under development (enquiry stage) and will replace the 2021 edition when published; not yet published, re-confirm the year before quoting.
• NIST SP 800-34 Rev 1, Contingency Planning Guide for Federal Information Systems. The seven-step contingency planning process includes plan maintenance (Step 7), the document-control dimension of contingency planning.
• NIST SP 800-88 Rev 1, Guidelines for Media Sanitization. The canonical reference for secure disposal of media bearing documented information, directly relevant to the 7.5 disposition requirement.
• SOC 2 (Trust Services Criteria), the Availability and Confidentiality categories include controls for document availability, protection and retention that map closely to 7.5.

Recognised professional disciplines (citable, mapped TO)

Documented information control is not invented by ISO 22301; it draws on established information-governance and records-management disciplines. The most relevant for an Indian growing-company BCMS:

• Records management as practised under ISO 15489, the lifecycle discipline of creating, capturing, classifying, storing, accessing, using, retaining and disposing of records.
• Information governance, the enterprise discipline that treats information as an asset with a lifecycle, ownership, classification and risk.
• Digital preservation, the discipline of keeping electronic documents readable over decades, including format migration and media refresh.
• Audit evidence standards, the discipline of designing records so they prove conformity at the point of origin, rather than reconstructing evidence after the fact.
• Recognised BCM professional practices, the documented-information thread that runs through recognised practitioner bodies of knowledge and certification curricula (the BCI and DRI certifications are recognised credentials in the Indian market; their professional practices cover the documentation discipline a BCM practitioner is expected to master). These are routes to practitioner competence; they are not the clause itself.
• CERT-In advisories and the CERT-In PoC network, the active channel through which Indian ICT operators receive and acknowledge incident-response documentation obligations, including the 180-day log and 5-year KYC clocks.
• NDMA Do's-and-Don'ts public-communication material, freely reusable documentation artefacts for natural-hazard scenarios, available in Indian languages from ndma.gov.in; usable in the BCM document set for the workforce and the surrounding community.

These disciplines are routes to documented-information competence; they are not the clause. An auditor will ask: "Is your document hierarchy defined, are your versions controlled, is your retention schedule compliant, is your evidence retrievable?", not "which records-management school do you follow?".

Why This Control Matters

The business risk of uncontrolled documentation

A BCMS is, at its core, a set of decisions made in advance and written down so they can be executed under stress. The documented information is the substrate on which every other clause operates. When that substrate is uncontrolled, three failure modes follow.

Failure mode 1, the plan is not the plan in force. When the BC plan exists in four versions on a shared drive with names like "BCP_v3.docx", "BCP_v3_final.docx", "BCP_v3_FINAL_real.docx" and "BCP_v3_USE_THIS.docx", no one, not the Crisis Management Team, not the auditor, not the regulator, can tell which version was in force on the day of the disruption. The CMT activates "the plan", but each member is reading a different version. The contact tree has the wrong phone numbers because the update was saved to the wrong file. The invocation authority is ambiguous because the approval signature is on a version that was superseded. This is not a theoretical risk; it is the single most common documentation failure in the Indian growing-company segment, and it is the failure mode that converts a manageable disruption into a chaotic one.

Failure mode 2, the plan is destroyed by the disruption it is designed to manage. When the BC plan exists only on the system it is supposed to recover, a ransomware encryption event or a data-centre fire takes the plan down alongside the operations. The CMT cannot invoke a plan it cannot read. This is the AIIMS Delhi 2022 failure pattern, primary and backup servers encrypted together, the documented procedures for recovery inaccessible on the very systems that needed recovery. The offline copy of the BC plans is not a nice-to-have; it is the precondition for the BCMS to function at all during a disruption. ISO 22301 Clause 7.5's "availability" and "protection" requirements are, in the BCM context, the requirement that the documentation survives the disruption.

Failure mode 3, the evidence of conformity is irretrievable. A BCMS that cannot produce, on demand, the current version of its policy, the latest BIA, the last exercise report, the last audit report, the last management-review minutes and the last corrective-action record is a BCMS that cannot be certified and cannot be defended to a regulator. The certification audit is, in large part, a document-retrieval exercise; the auditor asks "show me", and the organisation must produce. A regulator after a disruption asks the same question, with higher consequences. The 7.5 "control" obligation is the obligation to make the evidence retrievable, not eventually, not "we can find it if you give us a week", but on demand, in the current version, with the version history that proves it was in force when it mattered.

The Indian regulatory context

The Indian regulatory environment makes 7.5 not a back-office discipline but a board-level compliance obligation. Five regulatory currents converge on documented information:

First, the retention clocks. CERT-In Directions (28 April 2022) require ICT system logs to be maintained for 180 days within Indian jurisdiction, and KYC and customer data for VPN, data-centre, cloud and anonymous-service customers to be maintained for 5 years. IRDAI Information and Cyber Security Guidelines (24 April 2023) require 180-day log retention aligned with CERT-In. The RBI Master Direction on IT Governance (7 November 2023, effective 1 April 2024) requires documented RTO/RPO, documented critical-systems classification and documented BCP/DR arrangements. SEBI CSCRF (20 August 2024) and SEBI MII BCP-DR (22 March 2021) require documented recovery architecture, drill records and incident-reporting records. These are not generic "keep good records" exhortations; they are specific retention periods with specific regulatory consequences for non-compliance.

Second, the data-erasure duty. The DPDP Act 2023 and the DPDP Rules 2025 impose a data-erasure duty on Data Fiduciaries, personal data must be erased when the purpose for which it was collected is no longer served, unless retention is required by law. This intersects directly with 7.5's retention-and-disposition requirement: where documented information contains personal data (and most BCMS records do, contact trees, BIA interviews, exercise participant lists, incident reports naming individuals), the retention schedule must reconcile the BCM need-to-retain with the DPDP duty-to-erase. The legal-hold workflow, where a record is preserved beyond its normal retention period because of anticipated or ongoing litigation or regulatory inquiry, is the mechanism that resolves the tension, and it must be documented.

Third, the breach-notification documentation. CERT-In requires cyber-incident reporting within 6 hours; the DPDP requires breach notification to the Data Protection Board within 72 hours and to affected Data Principals without delay; RBI requires bank-incident reporting within 2 to 6 hours; SEBI requires MII cyber-incident reporting within 6 hours. Each of these notifications is itself a documented-information event, the notification must be drafted, approved, sent, and the evidence of sending and timing retained. A 7.5-conformant regime captures this evidence at the point of origin; a non-conformant regime tries to reconstruct it after the fact, which is how organisations miss the clock.

Fourth, the board-oversight documentation. The Companies Act 2013 Section 134(3)(n) requires the Board's Report to include a statement on the development and implementation of a risk management policy. Section 177 and SEBI LODR Regulation 21 require the Risk Management Committee to evaluate internal financial controls and risk management systems. These are documented-information obligations on the board itself, and the BCMS documentation, the policy, the BIA, the exercise reports, the management-review minutes, is the evidence the board relies on to discharge them. A BCMS whose documentation is not board-ready is a BCMS whose board cannot discharge its statutory duty.

Fifth, the critical-information-infrastructure dimension. The IT Act 2000 Section 70A establishes NCIIPC as the National Nodal Agency for Critical Information Infrastructure Protection. Entities operating protected systems have enhanced documentation obligations, the protected-system notification, the security architecture documentation, the incident-response documentation. Where the BCMS covers a protected system, 7.5's control regime must meet the NCIIPC expectations as well.

The cost of non-compliance

The cost of 7.5 non-compliance is rarely a stand-alone penalty; it is the multiplier on every other failure. When a disruption occurs and the documentation is not available, not current or not protected, the consequences cascade: the response is slower (because the plan is not readable), the regulator is informed late (because the notification procedure is not retrievable), the audit fails (because the evidence is not producible), the corrective action is weak (because the root-cause record is incomplete), and the next disruption repeats the pattern (because the lessons learned were not captured). The Cognizant Maze ransomware (April 2020, SEC-filed Q2 2020 impact of US$50 to 70 million) and the AIIMS Delhi ransomware (November 2022, primary and backup servers encrypted together) are both, at their documentation core, 7.5 failures, the documented recovery procedures and the documented backup regime did not survive the disruption. The HDFC Bank RBI action (2 December 2020, barred from new digital products and fresh credit cards) was, in part, a documentation-governance failure, the regulator treated the repeated outages as evidence that the documented continuity arrangements were not adequate, not current and not effective.

The opportunity

A 7.5-conformant documented-information regime is not just a defence against failure; it is an operational asset. A clean document hierarchy means new joiners find the BC plan on day one. A versioned change log means the post-disruption review can reconstruct what was in force and what changed. A retention schedule means storage costs are bounded and legal-discovery risk is contained. An offline copy of the BC plans means the CMT can invoke from anywhere. An evidence-by-design framework means the certification audit is a retrieval exercise, not a reconstruction project. For a growing company, the documented-information regime is also the scalability mechanism, the BCMS that depends on the BCM Manager's memory does not scale beyond the BCM Manager, but the BCMS that depends on a controlled document set scales with the organisation.

Scope and Applicability

What documented information is in scope

Clause 7.5 applies to all documented information the BCMS requires, both the documented information the standard explicitly requires and the additional documented information the organisation determines is necessary for the effective operation of the BCMS. The scope is best understood through the four-tier document hierarchy that an Indian growing-company BCMS typically maintains:

Tier 1, Apex governance documents. The BCMS Policy (Clause 5.2), the BCMS Scope (Clause 4.3), the BC Objectives and their plans (Clause 6.2), the Risk Management Policy where integrated, the Information Security Policy where integrated. These are the board-approved, top-management-owned documents that set the direction. They are the highest-control documents, every change is material, every version is approved at the top-management level, every publication is a communication event under Clause 7.4.

Tier 2, Management and planning documents. The BIA (Clause 8.2), the Risk Assessment (Clause 8.2), the Business Continuity Strategies and Solutions document (Clause 8.3), the BCM Communication Plan (Clause 7.4), the Exercise Programme (Clause 8.5), the Documented Information Control Policy itself (Clause 7.5), the Internal Audit Programme (Clause 9.2), the Management Review schedule (Clause 9.3). These are the BCM-Manager-owned documents that translate the apex direction into plans. They are medium-control, reviewed annually and on trigger, approved by the BCM Steering Committee or equivalent.

Tier 3, Operational plans and procedures. The BC Plan set (Clause 8.4), the response structure, the invocation procedures, the incident response plan, the IT DR plan, the work-area recovery plan, the crisis communication plan, the supplier-failover plan, the occupant-evacuation plan, the manual-workaround procedures. The operational procedures, the document control procedure, the communication procedure, the exercise procedure, the audit procedure, the corrective-action procedure. These are the plan-owner-owned documents that direct the response. They are high-frequency-change documents, reviewed after every exercise, every disruption and every significant organisational change.

Tier 4, Records. The evidence the BCMS generates, exercise reports, audit reports, management-review minutes, nonconformity and corrective-action records, monitoring and measurement records, competence records, awareness records, communication records, incident logs, regulator-notification records, BIA interview records, version-and-change logs, retention-and-disposal records. These are the point-of-origin records that prove conformity. They are append-only, once created, they are not revised; they are superseded by a new record with a new date.

Scope by organisation size

Small (10 to 50 staff). A single-tier document set may suffice, the BC policy, the BC plan, the BIA summary, the exercise schedule, the audit checklist, the contact tree. The document hierarchy is implicit but documented. The version control is a naming convention and a change log. The retention schedule is a one-page table. The protection regime is access control on the shared drive and an offline copy of the BC plan. The whole regime can be maintained by the BCM Manager (often a dual-hatted role) in a few hours a month.

Growing companies (50 to 250 staff). The four-tier hierarchy becomes necessary. The apex documents are board-approved. The management documents are steering-committee-approved. The operational plans are plan-owner-approved. The records are captured at the point of origin. A document-management system or a GRC platform becomes cost-justified. The retention schedule is a multi-page table reconciling CERT-In, IRDAI, RBI, SEBI, DPDP, Companies Act and IT Act clocks. The protection regime includes backup, access control and an offline copy stored off-site.

Mid-market (250 to 2,000). The regime is enterprise-grade. A document-management or GRC platform is standard. The retention schedule is a managed register with legal-hold workflows. The external-origin document register is maintained. The change-control workflow is integrated with the IT change-management process. The protection regime includes backup, access control, integrity protection, confidentiality classification and an offline copy distributed to multiple locations. The evidence-by-design framework is operational, every BCMS process generates its records automatically.

Multi-entity enterprise (2,000+). The regime is group-integrated. Group information governance sets the standard; entities apply it. Multi-jurisdiction retention obligations are reconciled (RBI for banks, SEBI for MIIs and brokers, IRDAI for insurers, CERT-In for all ICT operators, NDMA for industrial sites, NCIIPC for critical information infrastructure, plus any international regulator, DORA for EU financial exposure, MAS for Singapore, APRA for Australia, HKMA for Hong Kong). The document hierarchy is published as a group standard. The version control is centralised. The retention schedule is a group register with local variations. The protection regime is enterprise-grade with defence-in-depth.

Scope by industry

The 7.5 scope varies by industry because the regulatory retention clocks and the documentation criticality vary:

• BFSI (banks, NBFCs, payment system operators, insurers). The most documentation-heavy sector. RBI MD IT Governance, SEBI CSCRF, IRDAI Guidelines, CERT-In Directions all apply. The retention schedule is the most complex. The BC plan set is the most extensive. The regulator oversight is the highest.
• Healthcare. Patient-safety documentation, clinical-continuity procedures, the e-Hospital system documentation, the patient-data retention under DPDP. The AIIMS Delhi 2022 ransomware is the cautionary tale, the documented recovery procedures and the documented backup regime did not survive the disruption.
• IT/ITeS and SaaS. The BCP/DR documentation for client-facing services, the SLA documentation, the incident-response documentation, the data-locality documentation. Where serving EU financial clients, DORA documentation requirements apply.
• Manufacturing (especially chemical and pharma). The on-site and off-site emergency plans under NDMA Chemical Disaster Guidelines, the MAH (Major Accident Hazard) documentation, the OT/IT segmentation documentation. The LG Polymers Vizag 2020 styrene gas leak (NGT interim penalty of ₹50 crore) is the cautionary tale, the documented emergency procedures were inadequate.
• Government and public sector. The Disaster Management Plan documentation under DM Act 2005 Section 40, the NDMA DMP template, the integration with District DMPs, the e-governance documentation under IT Act Section 84A.

Key Definitions and Terminology

The vocabulary of documented information is precise and often conflated. The following definitions are paraphrased from ISO 22300:2021 and ISO 15489-1:2016; verify exact wording against the official standards before quoting verbatim.

Documented information. In our own words: the information an organisation is obliged to keep under control and keep current, together with whatever carries it, whether a file, a database record, a wiki page, or paper. The term encompasses both documents (information that can be changed, like a policy or a plan) and records (information that captures an event or state and is not changed, like an exercise report or an audit finding). ISO 22301 uses "documented information" to unify what earlier standards called "documents" and "records", the distinction is retained operationally but the control regime is unified.

Document. Information that is subject to change through a controlled process. A policy, a procedure, a plan, a BIA, a strategy. Documents have versions; each version supersedes the previous. The current version is "in force"; superseded versions are archived.

Record. Information that captures an event, a decision or a state at a point in time and is not subsequently changed. An exercise report, an audit finding, a management-review minute, a nonconformity record, a corrective-action record, a communication log, a regulator-notification record. Records are append-only; if a record needs correction, a new record is created that supersedes or annotates the original, and both are retained.

Version. A numbered iteration of a document, incremented through the change-control process. The version number, the effective date and the approver identity together identify "which version was in force when", the question an auditor or a regulator asks after an incident.

Change log. The chronological record of changes to a document, version number, date, author, change description, approver, effective date. The change log is the evidence that the document was updated through a controlled process rather than edited in place.

Retention period. The defined duration for which a record class is kept before disposition. Retention periods are set by the organisation's needs and by the regulatory clocks that apply, CERT-In 180 days for ICT logs, 5 years for VPN/cloud/data-centre KYC; IRDAI 180 days for logs; Companies Act 8 financial years for books of account; DPDP "purpose no longer served" for personal data; plus the organisation's own BCM needs (e.g., retaining exercise reports for at least the certification cycle).

Disposition. The end-of-life action on a record, secure destruction, transfer to an archive, or transfer to a successor entity. Disposition must be evidenced, the record of what was disposed of, when, by whom and by what method.

External-origin document. A document of external origin that the BCMS references or relies on, an ISO standard, a regulator circular, a supplier contract, a certificate, a vendor's BCP summary. The organisation does not author it, but it must control its distribution and updating (i.e., ensure the current version is in use and superseded versions are withdrawn).

Suitability. The property of documented information being fit for its purpose, the right level of detail, the right format, the right audience, the right currency. An auditor tests suitability by asking "does this document do what it is supposed to do?".

Adequacy. The property of documented information being complete and correct for its purpose. An auditor tests adequacy by asking "is this document complete, and is it correct?".

Availability. The property of documented information being accessible where and when it is needed, including during a disruption, by the people who need it, in a readable format. Availability is the 7.5 property most directly tested by a disruption.

Protection. The property of documented information being defended against loss of confidentiality, integrity, availability and improper use, through access control, backup, integrity protection, classification and physical security.

Legal hold. The suspension of the normal retention-and-disposition schedule for a record class because of anticipated or ongoing litigation, regulatory inquiry or investigation. A legal hold overrides the disposal schedule until released.

Evidence by design. The practice of designing BCMS processes so that the records that prove conformity are captured automatically at the point of origin, rather than reconstructed after the fact. Evidence by design is the difference between an audit that is a retrieval exercise and an audit that is a reconstruction project.

Metadata. The structured information about a document or record, title, author, date, version, owner, classification, retention class, reference number. Metadata is what makes a document retrievable and controllable at scale.

Relationship to Other Clauses and Frameworks

Relationship to other ISO 22301 clauses

Clause 7.5 is the evidence layer that makes every other clause auditable. The relationship is bidirectional: every clause generates documented information that 7.5 controls, and 7.5 enables every clause by ensuring its evidence is available, current and protected.

• Clause 4 (Context). The scope (4.3) is documented information. The context analysis (4.1) and the interested-party analysis (4.2) are documented information. 7.5 ensures these are controlled, current and approved.
• Clause 5 (Leadership). The BC policy (5.2) is the apex documented information. The role assignments (5.3) are documented information. 7.5 ensures the policy is version-controlled, approved, communicated and available, the policy that no one can find or that is six versions out of date is non-conformant however well-written.
• Clause 6 (Planning). The objectives (6.2) and their plans are documented information. The risk and opportunity actions (6.1) are documented information. The planning of changes (6.3) is itself a document-control event, a change to the BCMS is a version increment to the affected documents.
• Clause 7 (Support). 7.1 resources are documented (budget, people, infrastructure). 7.2 competence evidence is documented information (training records, qualifications, experience records). 7.3 awareness evidence is documented information (awareness-session records, acknowledgement records). 7.4 communication evidence is documented information (communication logs, notification records). 7.5 is the framework that controls all of these.
• Clause 8 (Operation). The BIA (8.2), the strategies (8.3), the plans (8.4), the exercise programme (8.5) and the evaluation (8.6) are all documented information, and the BC plan set (8.4) is the most critical documented information 7.5 protects, because it is the document the CMT needs on the worst day.
• Clause 9 (Evaluation). The monitoring records (9.1), the audit programme and reports (9.2) and the management-review minutes (9.3) are documented information. 7.5 ensures these are retained for the certification cycle and beyond.
• Clause 10 (Improvement). The nonconformity and corrective-action records (10.1) and the continual-improvement records (10.2) are documented information. 7.5 ensures the corrective-action loop is evidenced, a corrective action without a record is an assertion, not a correction.

Relationship to ISO/IEC 27001:2022

ISO 22301 Clause 7.5 and ISO/IEC 27001:2022 Clause 7.5 are structurally identical (the Harmonized Structure). An integrated BCMS/ISMS treats documented information once, the same document-control regime satisfies both. The differences are in the kinds of documented information prioritised: ISO 27001 emphasises the information-security policy, the risk assessment, the risk treatment plan, the Statement of Applicability and the Annex A control evidence; ISO 22301 emphasises the BC policy, the BIA, the strategies, the plans and the exercise evidence. In an integrated programme, the document hierarchy includes both sets.

The ISO 27001 Annex A controls that most directly intersect with 7.5 are: A.5.29 (information security during disruption, the documentation must be available during disruption), A.5.30 (ICT readiness for business continuity, the documentation infrastructure must be ready), A.8.13 (information backup, the documented information must be backed up), A.8.14 (redundancy of information processing, the documentation must be redundant), A.5.12 (classification of information, the documents must be classified), A.5.34 (privacy and protection of personal data, records containing personal data must be protected per DPDP), A.8.10 (information deletion, disposition must be secure and evidenced), and A.5.33 (physical and environmental security, paper documents must be physically protected).

Relationship to NIST SP 800-34 Rev 1

NIST SP 800-34 Rev 1's seven-step contingency planning process includes Step 7 (Plan Maintenance), the document-control dimension. Step 7 requires the ISCP to be reviewed and updated regularly, with a change log, version control and a review cycle tied to the system's lifecycle. This maps directly to 7.5's "update" and "control" obligations. The NIST BIA Template and the ISCP templates (for Low, Moderate and High impact systems) are document-control artefacts that 7.5 governs.

Relationship to DORA

DORA (Regulation (EU) 2022/2554, applicable from 17 January 2025) imposes documented-information requirements on in-scope financial entities. Article 6(5) requires the ICT risk management framework to be documented. Article 9 requires ICT-related incident documentation. Article 11(1) requires an ICT business continuity policy. Article 11(5) requires a Business Impact Analysis. Article 12 requires backup policies and restoration documentation. Article 28 requires a register of information on ICT third-party arrangements. Each of these is documented information under 7.5 control, an Indian IT/BPO firm serving EU financial clients must meet both the ISO 22301 7.5 regime and the DORA documentation requirements.

Relationship to APRA CPS 230

APRA CPS 230 (effective 1 July 2025) paragraph 40 requires the BCP to be documented with the critical-operations register, triggers, actions, resources and communications. Paragraph 43 requires an annual business-continuity exercise and documentation of the results. These map to 7.5's "create" and "control" obligations for the BCP and the exercise records.

Relationship to SOC 2

SOC 2's Trust Services Criteria include the Availability category (the system is available for operation and use) and the Confidentiality category (information is protected from unauthorised access). Both include controls for document availability, protection and retention that map closely to 7.5. A SOC 2 auditor will test whether the BCMS documentation is available, protected and retained, the same tests a 22301 auditor applies.

Relationship to the Indian regulatory instruments

The 7.5 control regime is the single regime that satisfies the documentation expectations of all the Indian regulators simultaneously, provided the retention schedule reconciles every clock. The mapping is densest for the retention clocks (CERT-In 180 days / 5 years; IRDAI 180 days; Companies Act 8 years; DPDP erasure) and for the breach-notification documentation (CERT-In 6 hours; RBI 2 to 6 hours; SEBI 6 hours; DPDP 72 hours). A well-built 7.5 evidence set is also the evidence set a regulator asks for after a disruption, the same documents, the same records, the same version history.

Detailed Implementation Guidance, The Create-Update-Control Lifecycle

The 7.5 implementation is best understood as a lifecycle with three phases, Create, Update, Control, and eight disciplines that cut across them. The lifecycle is not linear; it is a continuous loop in which every controlled document is created once, updated many times, and controlled throughout.

The Document Hierarchy Matrix (the foundation)

Before any document is controlled, the organisation must know what documents it has. The Document Hierarchy Matrix is the master register, the single source of truth for what documented information the BCMS contains, who owns it, what format it is in, where it lives, how long it is retained and how it is protected. The matrix has one row per document or record class and the following columns at minimum: document identifier, title, tier (1 to 4), owner, approver, format, location, retention period, protection level, review cadence, current version, last review date, next review date, external-origin flag.

Building the matrix is the first implementation step. Most Indian growing companies start with a back-fill, listing every BCMS document that already exists, rating each against the seven control dimensions, and identifying the gaps. The matrix is then maintained as a controlled document itself (a Tier 2 management document), reviewed at least annually and on every document-creation or document-retirement event.

Create, identification, format, media, review and approval

Identification and description. Every controlled document must have appropriate identification and description. The minimum identification set is: a unique document identifier (a reference number), a title, a version number, a date of issue, an author, an approver, and a status (draft, in review, approved, published, superseded, archived). The identification is captured in the document's metadata and on the document's face (the cover page or header). The naming convention is defined in the Format and Media Standard and applied uniformly, a document whose filename is "BCP_final_v4_real.docx" is not identified; it is named.

Format and media. The organisation must decide, for each document class, the suitable format and media. The decision is per document class, not enterprise-wide, because suitability varies. The considerations are: readability over the retention period (an electronic document in a proprietary format that becomes unreadable in five years is non-conformant), accessibility during a disruption (an electronic document on the system that is down is non-conformant), usability by the audience (a printed procedure posted at the assembly line is more usable than a portal document for shop-floor staff), and protection (an electronic document with access control and backup is more protected than a paper document in an unlocked cabinet). Most Indian growing companies operate a hybrid regime, electronic for the working copy, printed for the disruption copy, with the printed copy stored off-site. The Format and Media Standard defines the acceptable electronic formats (PDF/A for long-term retention, the source format for the working copy), the naming convention, the metadata standard, and the print-and-distribute rules for the disruption copy.

Review and approval. Every controlled document must be reviewed for suitability and adequacy and approved by a named approver before publication. The review is a documented event, the reviewer is named, the review date is recorded, the review outcome is captured. The approval is a documented event, the approver is named, the approval date is recorded, the approval is signified (signature, electronic signature, workflow approval). The approval authority is defined in the Document Hierarchy Matrix, Tier 1 documents are approved by top management, Tier 2 by the BCM Steering Committee, Tier 3 by the plan owner, Tier 4 records are captured at the point of origin without a separate approval (the process that generates them is the approval).

Update, the review-on-trigger and the versioned change

The review cadence. Every controlled document has a defined review cadence, annual at minimum for Tier 1 and Tier 2 documents, and after every exercise, every disruption and every significant organisational change for Tier 3 documents. The review cadence is recorded in the Document Hierarchy Matrix, and the next review date is tracked. A document that is past its review date is a non-conformity, the organisation must either review it or formally extend the review date with a documented rationale.

The review-on-trigger. Beyond the scheduled review, certain triggers require an immediate review: a regulatory change (a new RBI circular, a SEBI amendment, a DPDP rule), an organisational change (a restructuring, a new product, a new site, a new critical supplier), a post-disruption review (the disruption revealed a documentation gap), an exercise outcome (the exercise revealed a plan defect), an audit finding (the audit identified a documentation non-conformity), and a corrective action (the corrective action requires a document change). The review-on-trigger is documented, the trigger is recorded, the review is conducted, the outcome is captured.

The versioned change. When a document is changed, the change is versioned. The version number is incremented (major version for material changes, minor version for editorial changes, the convention is defined in the Format and Media Standard). The change description is recorded in the change log. The changed document is reviewed and approved. The publication is a communication event under Clause 7.4, the stakeholders who need to know about the change are informed. The superseded version is archived, not deleted (it may be needed to answer "which version was in force when"). The effective date is recorded, the date the new version comes into force, which may be different from the approval date if a transition period is needed.

Control, availability, protection, distribution, retention, disposal

Availability. Documented information must be available where and when it is needed. For the BCMS, "when it is needed" includes during a disruption, which means the BC plan set must be available when the primary system is down. The availability design has three layers: the online copy (the working copy on the document-management system or shared drive), the offline electronic copy (on a device that is not connected to the primary network, a laptop, a tablet, a USB drive held by the BCM Manager and the CMT Chair), and the printed copy (stored off-site, in a location accessible to the CMT). The three copies are reconciled at every version change, the offline and printed copies are updated when the online copy is versioned. The availability design also covers the contact tree, the most frequently outdated document, which must be available out-of-band (printed, on a card, in the BCM Manager's and CMT members' wallets).

Protection. Documented information must be adequately protected from loss of confidentiality, integrity, availability and improper use. The protection regime has five elements: access control (who can read, who can edit, who can approve, defined per document class in the Document Hierarchy Matrix), backup (the document set is backed up with the same RPO as the critical systems it documents, the AIIMS failure of primary and backup together is the cautionary tale), integrity protection (version control, change log, hash or signature where the document's integrity is critical), confidentiality classification (each document is classified, Public, Internal, Confidential, Restricted, and the protection matches the classification), and physical security (paper documents are stored in locked cabinets, access-controlled rooms, fire-rated safes for the most critical). The protection regime is co-owned by the BCM Manager and the CISO, because the document set is a high-value information asset.

Distribution, access, retrieval and use. The organisation must control who receives the document, who can access it, how it is retrieved, and how it is used. Distribution is the push, the document is sent to the named recipients on publication. Access is the pull, the document is retrievable by the authorised users on demand. Retrieval is the test, can the right person find the right document in the right version within a reasonable time? Use is the purpose, the document is used for the purpose it was created for, and improper use (e.g., sharing a Confidential document externally) is prevented. An auditor tests retrieval by asking for a randomly selected document and timing the retrieval.

Storage and preservation. Documented information must be stored and preserved in a way that keeps it readable and usable throughout its retention period. For electronic documents, this includes format migration (the PDF/A format is designed for long-term retention; proprietary formats may need migration), media refresh (storage media degrade over time, optical media, magnetic media, solid-state media all have finite lifetimes), and backup integrity (backups must be tested by restoration). For paper documents, this includes environmental controls (temperature, humidity, fire protection, pest control) and physical security. The storage and preservation regime is documented and tested.

Control of external-origin documents. Documents of external origin, ISO standards, regulator circulars, supplier contracts, certificates, vendor BCP summaries, must be controlled for distribution and updating. The External-Origin Document Register lists each external-origin document, its source, its version, its date, its owner (the person responsible for monitoring the source for updates), its distribution, and its review cadence. The organisation must ensure the current version is in use and superseded versions are withdrawn. This is particularly important for regulator circulars, a BCMS that references a superseded RBI circular or a withdrawn ISO edition (the 2015 editions of ISO/TS 22317 and 22318 are withdrawn; the 2018 edition of ISO 22300 is withdrawn) is non-conformant.

Retention and disposition. The organisation must manage how long each record class is retained and how it is disposed of at end-of-life. The Records Retention and Disposal Schedule is the master artefact, one row per record class, with the retention period, the retention basis (which regulatory clock or business need drives the period), the disposition method (secure destruction, transfer to archive, transfer to successor), the disposition evidence requirement, and the legal-hold override. The schedule reconciles every Indian regulatory clock: CERT-In 180-day ICT logs and 5-year KYC; IRDAI 180-day logs; Companies Act 8 financial years for books of account; RBI and SEBI record-retention expectations; DPDP erasure-when-purpose-served; plus the organisation's BCM needs (exercise reports retained for the certification cycle, audit reports retained for at least three cycles, corrective-action records retained until the corrective action is verified effective). Disposition is executed on schedule, evidenced (the record of what was disposed of, when, by whom, by what method), and the evidence is itself a retained record. Secure destruction for electronic media follows recognised media-sanitization practice (the NIST SP 800-88 Rev 1 approach is the recognised reference); for paper, cross-cut shredding or controlled incineration.

The eight disciplines that cut across the lifecycle

1. Identification and metadata discipline. Every document and record has the minimum metadata, captured at creation, maintained through the lifecycle.
2. Version and change-log discipline. Every change is versioned, every version has a change-log entry, every change-log entry names the author, the approver and the effective date.
3. Review-on-trigger discipline. The review is not only scheduled; it is triggered by regulatory change, organisational change, post-disruption review, exercise outcome, audit finding and corrective action.
4. Availability-and-suitability discipline. The document is available in the right place at the right time in the right format for the right audience, including during a disruption.
5. Protection-and-backup discipline. The document set is defended against ransomware, theft, tampering and loss, access-controlled, backed up, integrity-protected, classified, physically secured.
6. Retention-and-disposal discipline. Every record class has a retention period reconciled with every regulatory clock, and disposal is executed, evidenced and secure.
7. External-origin discipline. External-origin documents are registered, current, distributed and updated.
8. Evidence-by-design discipline. The records that prove conformity are captured at the point of origin, not reconstructed after the fact.

The offline-copy design (the BCM-critical 7.5 control)

The single most important 7.5 control in the BCM context is the offline copy of the BC plan set. The BC plans are the documents the CMT needs to invoke during a disruption; if those documents are on the system that is down, the BCMS cannot function. The offline-copy design has four elements: the offline electronic copy (on a device not connected to the primary network, a dedicated laptop, a tablet, an encrypted USB drive, held by the BCM Manager, the CMT Chair and at least one deputy each), the printed copy (a bound, indexed set stored off-site, at the alternate site, at the BCM Manager's home, at the CMT Chair's home, in a fire-rated safe at a different location), the contact-tree card (a wallet card with the CMT members' phone numbers, the regulator PoCs, the critical suppliers, the most frequently needed and most frequently outdated document), and the reconciliation cadence (the offline copies are reconciled with the online copy at every version change, and the reconciliation is evidenced).

The offline-copy design is tested in every exercise, the exercise begins with the CMT retrieving the offline copy and invoking from it, not from the online system. An exercise that assumes the online system is available is not testing the BCMS; it is testing the IT infrastructure.

Tools, Technologies, and Solutions

Clause 7.5 does not require a specific technology, but the right tooling dramatically reduces the effort and improves the discipline. The choice of tooling is a Clause 7.1 resourcing decision, scaled to the organisation's size, complexity and budget. The following categories are relevant; evaluate each against the organisation's needs, and select category-appropriate tools. Vendor and product names are deliberately omitted, the evaluation is by capability, not by brand.

Tool categories

Document Management System (DMS). The foundation for most growing companies. A DMS provides version control, metadata, access control, check-in/check-out, workflow approval, full-text search, retention policies and audit trails. The right DMS for a 200-person company is not the right DMS for a 20-person company; the evaluation criteria are scalability, ease of use, integration with the collaboration platform, retention-policy enforcement, and audit-trail completeness. Typical Indian-market cost for a mid-market DMS: ₹500 to ₹2,000 per user per month, plus implementation.

Enterprise GRC platform. For mid-market and enterprise, a GRC platform integrates document control with risk management, audit management, corrective-action tracking, and policy management. A GRC platform is cost-justified when the document set exceeds a few hundred controlled documents, when the retention schedule is multi-jurisdiction, or when the organisation runs an integrated BCMS/ISMS/QMS. Typical Indian-market cost for a mid-market GRC platform: ₹2,000 to ₹6,000 per user per month, plus implementation (often ₹15 to ₹40 lakh for a 250-person company).

Records management system. For regulated industries (BFSI, healthcare), a dedicated records-management system with legal-hold workflow, disposition evidence, and compliance reporting may be required. This is distinct from a DMS, a DMS manages working documents; a records-management system manages records through their retention lifecycle.

Collaboration platform with versioning. For small organisations, a collaboration platform with version control, access control and metadata can serve as the DMS, provided the retention and disposition discipline is enforced through policy and procedure rather than the platform's native records-management capabilities. This is a viable starting point for a 50-person company; it is non-conformant for a 500-person regulated entity.

Version control repository. For technical documents (IT DR runbooks, infrastructure-as-code, configuration baselines), a version-control repository provides branching, merging, change history and integrity protection. This is complementary to, not a replacement for, the DMS, the DMS manages the BCMS documents; the repository manages the technical artefacts.

Backup and recovery infrastructure. The protection regime depends on backup. The backup infrastructure for the document set must meet the same RPO/RTO as the critical systems the documents describe, a 24-hour RPO on the document backup means a day's document changes could be lost. The AIIMS failure pattern (primary and backup encrypted together) is the cautionary tale, the backup must be offline, immutable, or air-gapped for the most critical documents. The 3-2-1 rule (three copies, two media, one off-site) is the recognised baseline; for BCMS documentation, a 4-3-2 variant (four copies, three media, two off-site, one offline) is prudent for the BC plan set.

Mass-notification and incident-communication platform. Relevant to 7.5 where the communication evidence (Clause 7.4) is documented information that must be captured at the point of origin. A mass-notification platform that logs every notification, its timing, its recipients and its content is an evidence-capture tool as well as a communication tool.

Media-sanitization and secure-disposal tools. For the disposition of electronic media bearing documented information, dedicated media-sanitization tools (secure-erase, cryptographic erase, physical destruction) ensure that disposed media cannot be reconstructed. The disposition evidence is captured in the retention-and-disposal register.

Evaluation criteria (category-level)

When selecting tooling, evaluate against the following criteria, weighted to the organisation's needs:

1. Version control completeness, does the tool capture every version, every change, every approver, every effective date?
2. Metadata support, does the tool enforce the minimum metadata at creation?
3. Access control granularity, can the tool enforce read/edit/approve per document class?
4. Retention-policy enforcement, can the tool enforce the retention schedule automatically, including legal hold?
5. Disposition evidence, does the tool capture the disposition event with the required evidence?
6. Audit trail, does the tool produce a complete audit trail for an auditor or regulator?
7. Availability design, does the tool support offline copies, out-of-band access?
8. Backup integration, does the tool integrate with the backup infrastructure?
9. Search and retrieval, can the right document be found in the right version within a reasonable time?
10. Integration, does the tool integrate with the collaboration platform, the ITSM platform, the GRC platform?
11. Scalability, does the tool scale from the current size to the target size?
12. Cost of ownership, licence, implementation, training, ongoing administration.
13. Data residency, for Indian regulated entities, does the tool support data residency within Indian jurisdiction (required by CERT-In and by several RBI and SEBI expectations)?
14. Regulatory alignment, does the tool support the specific Indian regulatory clocks (CERT-In 180 days, 5 years; IRDAI 180 days; Companies Act 8 years; DPDP erasure)?

Build vs buy

For most growing companies, buying a category-appropriate tool is more cost-effective than building a document-control regime on a generic shared drive. The break-even is typically around 100 controlled documents or 100 staff, below that, a well-disciplined shared drive with a controlled naming convention, a change log and a manual retention schedule can satisfy 7.5; above that, the manual effort becomes a non-conformity risk. The decision is a Clause 7.1 resourcing decision, and it should be revisited as the organisation grows.

The "no-tool" starting point

A growing company that cannot yet invest in tooling can start with a "no-tool" regime that is still 7.5-conformant: a controlled folder structure on the shared drive (one folder per tier, one subfolder per document class), a naming convention (DOC-ID_TITLE_VERSION_DATE), a change-log spreadsheet (one row per change), a retention-schedule spreadsheet (one row per record class), an external-origin-register spreadsheet, and a printed offline copy of the BC plan set stored off-site. This regime is auditable, provided it is disciplined. The risk is that the discipline depends on the BCM Manager's personal rigour, which does not scale.

Policy and Procedure Templates

The 7.5 policy and procedure set is the backbone of the documented-information regime. The following are the structures the organisation should build; the full ready-to-customise templates are in the toolkit.

The Documented Information Control Policy (apex)

The apex policy is a Tier 1 document, board-approved, owned by the BCM Manager, reviewed annually. Its structure: purpose and scope; the four-tier document hierarchy; the create-update-control lifecycle; the roles and authorities (who authors, who reviews, who approves, who custodies); the format and media standard; the availability and protection regime; the retention and disposal schedule (reference to the master schedule); the external-origin document control; the legal-hold workflow; the evidence-by-design principle; the integration with the BCMS Policy, the Information Security Policy and the Records Management Policy; the review cadence; the approval and publication.

Sample policy "shall" clauses (the organisation's own drafting, these are appropriate):

• "The Organisation shall maintain a Document Hierarchy Matrix identifying all documented information required by the BCMS, with owner, approver, format, retention period and protection level for each document and record class."
• "The Organisation shall ensure that every controlled document has appropriate identification, format, review and approval before publication."
• "The Organisation shall maintain an offline copy of the Business Continuity Plan set, reconciled with the online copy at every version change, stored off-site and out-of-band."
• "The Organisation shall maintain a Records Retention and Disposal Schedule reconciled with every applicable Indian regulatory retention requirement, including CERT-In, IRDAI, RBI, SEBI, DPDP and Companies Act obligations."
• "The Organisation shall ensure that disposition of documented information is executed on schedule, evidenced and secure."

The Documented Information Control Procedure

The procedure is a Tier 3 document, owned by the BCM Manager, reviewed annually and on trigger. Its structure: the create process (need identification, drafting, review, approval, publication, distribution); the update process (review-on-schedule, review-on-trigger, versioned change, re-approval, communication of change, archival of superseded version); the control process (availability design, protection regime, distribution and access, retrieval, storage and preservation, external-origin control, retention and disposal); the offline-copy procedure; the legal-hold procedure; the disposition procedure; the evidence-capture procedure; the KPI reporting procedure.

The Document Hierarchy Matrix

A Tier 2 document, owned by the BCM Manager, reviewed at least annually and on every document-creation or document-retirement event. The structure is described in section 7.1 above.

The Version Control and Change Log

A Tier 4 record, maintained per controlled document. The structure: document identifier, version number, date of change, author, change description, approver, approval date, effective date, superseded version, archival location.

The Records Retention and Disposal Schedule

A Tier 2 document, owned by the BCM Manager with the Company Secretary, reviewed at least annually and on every regulatory change. The structure: record class, description, retention period, retention basis (the regulatory clock or business need), disposition method, disposition evidence requirement, legal-hold override, last review date, next review date.

The Format and Media Standard

A Tier 2 document, owned by the BCM Manager with the Head of IT, reviewed annually. The structure: acceptable electronic formats (PDF/A for long-term retention, source format for working copy), naming convention, metadata standard, print-and-distribute rules for the disruption copy, media-refresh schedule, format-migration schedule.

The External-Origin Document Register

A Tier 2 document, owned by the BCM Manager, reviewed at least annually. The structure: document title, source, version, date, owner (the person monitoring the source), distribution, review cadence, current-status flag.

The Evidence-by-Design Framework

A Tier 2 document, owned by the BCM Manager with Internal Audit, reviewed annually. The structure: for each BCMS process, the records that prove conformity, the point of origin where each record is captured, the metadata captured, the retention class, the retrieval path.

Risk Assessment and Treatment

The 7.5 risk register

The documented-information regime has its own risk profile, the risks that the documentation fails when it is needed, or that the evidence is not available when it is asked for. The 7.5 risk register is a Tier 2 document, reviewed at least annually and on trigger. The following starter risks are the most common in the Indian growing-company segment:

Risk treatment patterns

The treatment patterns for 7.5 risks are drawn from the eight disciplines in section 7.5. The most common treatments are: the offline-copy design (for R1, R7, R11), the DMS with enforced versioning (for R2, R9), the review-cadence tracking (for R3), the retention schedule with automated enforcement (for R4, R5), the external-origin register (for R6), the access-control regime (for R8), the metadata and retrieval discipline (for R10), the disposition-evidence workflow (for R12), the legal-hold workflow (for R13), the format-migration schedule (for R14), and the deputy designation (for R15). Each treatment is documented in the risk register with an owner, a target date and a verification method.

The risk-based prioritisation

Not all 7.5 risks are equal. The prioritisation is by the product of impact and likelihood, with the highest priority given to risks that would cause the BCMS to fail during a disruption (R1, R7, R11) and risks that would cause a regulatory non-conformity (R4, R5). The prioritisation is reviewed annually and on trigger, and it drives the implementation roadmap.

Audit and Compliance Checklist

The following 28 questions are the audit instrument for ISO 22301 Clause 7.5. They are used both for the certification audit (Stage 1 and Stage 2) and for the Clause 9.2 internal audit. For each, the expected evidence and the red flag are noted.

1. Is there a Documented Information Control Policy, approved by top management, current and in force? Evidence: the policy document, version, approval, effective date. Red flag: policy missing, undated, or past its review date.
2. Is there a Documented Information Control Procedure, current and in force? Evidence: the procedure document, version, approval. Red flag: procedure missing or generic.
3. Is there a Document Hierarchy Matrix listing all BCMS documented information? Evidence: the matrix, completeness against the clause list. Red flag: matrix missing or incomplete.
4. Does the Document Hierarchy Matrix include owner, approver, format, retention period and protection level for each document and record class? Evidence: the matrix columns populated. Red flag: columns missing or blank.
5. For a sampled controlled document, is the identification complete (identifier, title, version, date, author, approver, status)? Evidence: the document's metadata and face. Red flag: identification incomplete or filename-based.
6. For a sampled controlled document, is the format and media suitable for its purpose and retention period? Evidence: the format decision, the media. Red flag: unsuitable format (e.g., proprietary format for long-term retention).
7. For a sampled controlled document, is there evidence of review and approval before publication? Evidence: the review record, the approval signature. Red flag: no review or approval evidence.
8. For a sampled controlled document, is there a version history and a change log? Evidence: the version history, the change log. Red flag: version history is the filename; change log absent.
9. For a sampled controlled document, is the review cadence defined and tracked, with a next review date? Evidence: the Document Hierarchy Matrix entry, the next review date. Red flag: no review cadence; document past its review date.
10. Is there evidence of review-on-trigger (regulatory change, organisational change, post-disruption, exercise, audit, corrective action)? Evidence: the trigger record, the review record. Red flag: no trigger-based review evidence.
11. Is there an offline copy of the BC plan set? Evidence: the offline copy, the location, the reconciliation record. Red flag: no offline copy; plans only on the primary system.
12. Is the offline copy reconciled with the online copy at every version change? Evidence: the reconciliation record. Red flag: no reconciliation; offline copy out of date.
13. Is the offline copy stored off-site and out-of-band? Evidence: the storage location, the out-of-band verification. Red flag: offline copy stored on the primary network.
14. Is there a contact-tree card available out-of-band (printed, on the BCM Manager and CMT)? Evidence: the card. Red flag: contact tree only on the system.
15. Is there a Records Retention and Disposal Schedule? Evidence: the schedule. Red flag: schedule missing.
16. Does the Retention Schedule reconcile the CERT-In 180-day log retention? Evidence: the schedule row for ICT logs. Red flag: CERT-In clock not reflected.
17. Does the Retention Schedule reconcile the CERT-In 5-year KYC retention? Evidence: the schedule row for KYC/customer data. Red flag: 5-year clock not reflected.
18. Does the Retention Schedule reconcile the IRDAI 180-day log retention (where applicable)? Evidence: the schedule row. Red flag: IRDAI clock not reflected.
19. Does the Retention Schedule reconcile the DPDP erasure duty for personal data in records? Evidence: the schedule row, the erasure workflow. Red flag: DPDP erasure not addressed.
20. Does the Retention Schedule reconcile the Companies Act 8-year book retention? Evidence: the schedule row. Red flag: Companies Act clock not reflected.
21. Is disposition executed on schedule, evidenced and secure? Evidence: the disposition record, the disposal method. Red flag: no disposition evidence; "keep everything forever".
22. Is there an External-Origin Document Register? Evidence: the register. Red flag: register missing.
23. For a sampled external-origin document, is the current version in use and the superseded version withdrawn? Evidence: the register entry, the distribution. Red flag: superseded version still in use; withdrawn ISO edition cited.
24. Is there a protection regime (access control, backup, integrity, classification, physical security)? Evidence: the protection regime documentation, the access-control matrix, the backup configuration. Red flag: protection regime absent; shared-drive permissions too broad.
25. Is the document set backed up with an RPO consistent with the criticality of the documents, including an offline/immutable copy? Evidence: the backup configuration, the restoration test. Red flag: backup on the same network as primary (AIIMS pattern).
26. Is there a legal-hold workflow? Evidence: the workflow, a sample legal-hold record. Red flag: no legal-hold workflow.
27. Can the organisation retrieve a randomly selected controlled document, in the current version, within a reasonable time, during an audit? Evidence: the retrieval test in the internal audit. Red flag: retrieval fails or is slow.
28. Is there evidence that the BCM Manager has a deputy who can operate the documented-information regime? Evidence: the deputy designation, the deputy's competence record. Red flag: single-person dependency.

Metrics and KPIs

Figure · Measures

The measures that show Clause 7.5 is working

The 7.5 KPI set measures the health of the documented-information regime. The KPIs feed the Clause 9.1 monitoring dashboard and the Clause 9.3 management review. The following 13 KPIs are the core set.

The dashboard is reported monthly to the BCM Steering Committee, quarterly to the Risk Management Committee (where applicable under SEBI LODR Reg 21), and annually to the board. The trend matters more than the absolute value, a K1 of 90% trending to 98% over four quarters is a healthier signal than a K1 of 95% trending to 88%.

The dashboard sample layout

A sample dashboard row (illustrative):

• Document class: BC Plan (Tier 3)
• Current version: 4.2
• Last review: 2026-06-15
• Next review: 2026-12-15 (or on trigger)
• Offline copy: Reconciled 2026-06-16; stored off-site (CMT Chair home safe); printed copy at alternate site
• Retention: Indefinite while in force; superseded versions archived for 6 years
• Protection: Confidential; access-controlled; backed up (immutable copy, 1-hour RPO)
• K1 status: Current. K2 status: Complete. K3 status: Reconciled. K8 status: Last retrieval test passed (2026-05-20, 4 minutes).

Common Pitfalls and Audit Failures

The following pitfalls are the most common 7.5 failure modes in the Indian growing-company segment. Each is named, explained, and accompanied by the antidote.

Pitfall 1, "BCP_final_v4_USE_THIS.docx". Filename-based versioning is not version control. The filename tells you nothing about who approved it, when it came into force, or what changed from the previous version. The auditor will sample a controlled document and ask for the version history; the filename is not a history. Antidote: a DMS or a disciplined change-log spreadsheet with a naming convention that enforces the metadata.

Pitfall 2, The plan on the system it recovers. The BC plan exists only on the shared drive, the shared drive is on the network, the network is down, the plan is inaccessible. This is the AIIMS failure pattern. Antidote: the offline-copy design, tested in every exercise.

Pitfall 3, "We keep everything forever." This is not a retention schedule; it is the absence of one. The auditor will ask for the retention schedule and the disposition evidence; "we keep everything" fails both. It also fails the DPDP erasure duty. Antidote: the Records Retention and Disposal Schedule, with disposition executed and evidenced.

Pitfall 4, The contact tree from last quarter. The contact tree is the most frequently outdated document because people change phone numbers, change roles, and leave the organisation. A stale contact tree means the CMT cannot be convened. Antidote: the contact-tree card, reconciled monthly and tested in every exercise.

Pitfall 5, No external-origin register. The BCMS references ISO 22301:2019, the RBI Master Direction, the CERT-In Directions, the DPDP Act, but no one is monitoring whether these have been updated. The organisation cites the withdrawn ISO/TS 22317:2015 instead of the current 2021 edition. Antidote: the External-Origin Document Register with a source-monitoring owner per document.

Pitfall 6, The documentation mountain. The organisation over-documents, a 200-page BC plan no one reads, a BIA that documents every process to the same depth, a set of procedures that duplicate the work instructions. The auditor flags this as an adequacy failure because the documents are not suitable for use. Antidote: the suitability test, is this document usable by its audience?

Pitfall 7, The backup that is encrypted with the primary. The document set is backed up, but the backup is on the same network, with the same credentials, and the ransomware encrypts both together. This is the AIIMS failure. Antidote: the 3-2-1 backup with an offline or immutable copy.

Pitfall 8, No review-on-trigger. The document is reviewed annually, but the regulatory change in March, the organisational change in May, and the exercise finding in July are not acted on until the next annual review in December. Antidote: the review-on-trigger, with triggers defined and monitored.

Pitfall 9, The single-person dependency. Only the BCM Manager knows where the documents are, what the versions are, and how the regime works. The BCM Manager is on leave, or has left, and the regime fails. Antidote: the deputy designation, the Document Hierarchy Matrix as the map, the documented procedure.

Pitfall 10, Evidence reconstructed after the fact. The audit approaches, and the organisation scrambles to reconstruct the evidence of the last exercise, the last audit, the last corrective action. The reconstructed evidence is incomplete, inconsistent, and flagged. Antidote: evidence by design, the records are captured at the point of origin.

Pitfall 11, Paper documents uncontrolled. The organisation has moved to electronic documents but maintains printed copies at the sites without controlling them, the printed copy on the wall is from 2023, the electronic version is 4.2, and no one knows which is in force. Antidote: the print-and-distribute rules in the Format and Media Standard, with the printed copy's version and date on its face.

Pitfall 12, No legal-hold workflow. A litigation or regulatory inquiry arises, the normal retention schedule continues, and a record that should have been preserved is disposed of. Antidote: the legal-hold workflow, triggered by Legal, overriding the disposal schedule.

Pitfall 13, Personal data in records not DPDP-aware. The BIA interview notes, the exercise participant lists, the incident reports naming individuals, these contain personal data, and the retention schedule treats them like any other record, missing the DPDP erasure duty. Antidote: the DPDP-aware retention schedule, with personal-data record classes identified and the erasure workflow defined.

Pitfall 14, The "approved" document with no approval evidence. The document states "Approved by: Top Management" but there is no signature, no date, no workflow record. The auditor asks "who approved this, and when?" and the answer is "the BCM Manager says it was approved". Antidote: the approval workflow with captured evidence, signature, electronic signature, workflow record.

Pitfall 15, Superseded versions deleted. The organisation, in a clean-up, deletes the superseded versions of the BC plan, leaving only the current version. The auditor asks "which version was in force during the June disruption?" and the answer is unrecoverable. Antidote: superseded versions are archived, not deleted, for the retention period.

Illustrative Scenario 1: Failure, Shree Vidyut Cooperative Bank (Illustrative)

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

Disclaimer: This is an illustrative scenario. The organisation, persons and specific event are fictional; the failure pattern is drawn from documented Indian incidents including the AIIMS Delhi ransomware (November 2022) and the HDFC Bank RBI action (December 2020), adapted for the documented-information angle. No specific real entity is implied.

The organisation

Shree Vidyut Cooperative Bank is an urban cooperative bank with 380 staff, 22 branches across two states, and a deposit base of approximately ₹4,200 crore. It is regulated by the RBI under the Complete Cyber Security Framework for UCBs (31 December 2019) and the RBI Master Direction on IT Governance (7 November 2023, effective 1 April 2024, applicable to UCBs above a threshold). The bank had a BCMS in name: a BC policy, a BC plan, a BIA summary, and an annual DR drill. It was preparing for ISO 22301 certification as a differentiator for its corporate-banking aspirations.

The documented-information regime (as it was)

The BCMS documentation lived on a single Windows file server at the head office, in a shared folder called "BCMS". The folder contained 147 files with names like "BCP_2023.docx", "BCP_2023_final.docx", "BCP_2023_final_real.docx", "BCP_2024_draft.docx", "BIA_summary_v2.pptx", "DR_drill_report_2023.pdf", and "contacts_phone_numbers.xlsx". There was no Document Hierarchy Matrix, no Version Control and Change Log, no Retention and Disposal Schedule, no External-Origin Document Register, and no offline copy of the BC plan. The BCM Manager, Priya Sharma, maintained the documentation on her personal drive and copied it to the shared folder when she remembered. The BC policy had been approved by the board in 2022 and not reviewed since. The contact tree was last updated when the previous CISO left in early 2024. The CERT-In PoC was the head of IT, who had not been told he was the PoC.

The disruption

On a Saturday morning in late monsoon, a ransomware payload, delivered via a phishing email opened by a branch officer the previous Tuesday, encrypted the Windows file server, the core banking system's application server, and the backup server. The backup server was on the same network, with the same domain credentials, and was encrypted alongside the primary. The ransom note demanded approximately ₹150 crore. The core banking system was down. The branch network was down. The ATM switch was down. UPI was down for the bank's customers.

The documentation failure

When the Crisis Management Team convened (by phone, because the contact tree on the file server was inaccessible), the first question was: where is the BC plan? The answer: on the encrypted file server. Priya Sharma had a copy on her laptop, but her laptop was being forensically examined because she had also clicked the phishing email. The deputy BCM Manager did not have a copy. The printed copy in the BCM Manager's drawer was the 2023 version, with the contact tree from 2023, including the previous CISO's phone number. The CERT-In PoC (the head of IT) was on leave in another state. The IR procedure could not be found. The regulator-notification procedure could not be found. The customer-communication holding statement could not be found.

The consequences

The CERT-In notification was made 11 hours after detection, nearly twice the 6-hour clock. The RBI notification was made 14 hours after detection, beyond the 2-to-6-hour window. The customer communication went out 26 hours after the outage began, by which time social media was already reporting the outage and customers were queueing at branches. The core banking system was restored after 62 hours from a rebuilt backup, with a data loss of approximately 9 hours of transactions (the last good backup was the previous night's batch). The BCMS documentation, including the BIA, the strategies, the plans, the exercise reports, the audit reports, and the management-review minutes, was lost, the superseded versions had been deleted in a 2024 clean-up, and the current versions were encrypted.

The regulatory aftermath

The RBI, under the Complete Cyber Security Framework and the Master Direction on IT Governance, initiated supervisory action. The bank was barred from opening new branches and from onboarding new corporate customers pending an external IT audit. A monetary penalty was imposed. The CERT-In direction-compliance failure (the 11-hour notification, the missing 180-day logs which were on the encrypted server, the missing PoC contactability) was separately flagged. The DPDP breach-notification obligation (the ransomware exfiltrated customer KYC data before encrypting) was triggered, and the 72-hour clock to the Data Protection Board was missed by a wide margin. The ISO 22301 certification audit, scheduled for the following month, was abandoned. The bank estimated the direct loss (penalty, remediation, forensic, legal, customer compensation, business loss) at approximately ₹38 crore, and the reputational loss was substantial.

The root-cause documentation analysis

The root cause was not the ransomware; the ransomware was the trigger. The root cause was a 7.5 failure. The BCMS documentation was uncontrolled (no version control, no change log), unprotected (no offline copy, no immutable backup, backup on the same network), unavailable during the disruption (only on the encrypted server), not current (the contact tree and the policy were stale), and not retained (superseded versions deleted). The evidence of conformity was irretrievable. The BCM Manager was a single-person dependency. The regime was non-conformant by construction; it just had not been activated yet. When it was activated, every 7.5 failure mode surfaced simultaneously.

The lessons

• The offline copy of the BC plan set is not a nice-to-have; it is the precondition for the BCMS to function during a disruption.
• The backup must be offline or immutable; a backup on the same network is not a backup.
• The contact tree must be available out-of-band and reconciled monthly.
• The CERT-In PoC must know they are the PoC, and must have a deputy.
• The retention schedule must not delete superseded versions of the BC plan; they are the evidence of "which version was in force when".
• The regulator clocks (CERT-In 6 hours, RBI 2 to 6 hours, DPDP 72 hours) must be wired into a documented notification procedure that is available out-of-band.
• A BCMS that depends on a single person is not a BCMS; it is a personal memory.

Illustrative Scenario 2: Success, Aarogya HealthTech Private Limited (Illustrative, with ROI)

Disclaimer: This is an illustrative scenario. The organisation, persons and specific figures are illustrative; the success pattern is drawn from documented Indian operational-resilience practices including the Cognizant Chennai 2015 flood response and the Akasa Air 2024 CrowdStrike response, adapted for the documented-information angle. No specific real entity is implied.

The organisation

Aarogya HealthTech Private Limited is a mid-market (650 staff) health-technology SaaS company headquartered in Pune, with a development centre in Hyderabad and a disaster-recovery site in Mumbai. It provides a clinical-continuity platform to 140 hospitals across India, including 30 teaching hospitals. Its platform hosts patient records, e-prescriptions, lab results and appointment systems. It is regulated under DPDP (as a Data Fiduciary of patient data, likely a Significant Data Fiduciary), CERT-In (as an ICT operator), and indirectly under IRDAI and the Clinical Establishments Act through its hospital customers. It was pursuing ISO 22301 certification as a contractual requirement of its largest hospital customer.

The documented-information regime (as built)

The BCM Manager, Rahul Sharma, built the documented-information regime over a 14-week programme, with the following artefacts:

• A Documented Information Control Policy, board-approved, defining the four-tier hierarchy, the create-update-control lifecycle, the roles and authorities, the format and media standard, the availability and protection regime, and the retention and disposal schedule.
• A Document Hierarchy Matrix listing 62 controlled documents and 28 record classes, with owner, approver, format, retention period and protection level for each.
• A Version Control and Change Log maintained in a mid-market GRC platform, with enforced versioning, approval workflow, and change-log capture.
• A Records Retention and Disposal Schedule reconciling CERT-In (180-day ICT logs, 5-year KYC for the cloud-service customer data), DPDP (erasure-when-purpose-served for personal data, with legal-hold override), the Companies Act (8-year books), and the hospital-customer contractual retention (10-year patient records, per the Clinical Establishments Act and hospital policy).
• An Offline-Copy Design: the BC plan set was maintained in three copies, the online working copy on the GRC platform, an encrypted offline electronic copy on dedicated laptops held by the BCM Manager, the CMT Chair and the deputy BCM Manager, and a printed bound copy stored in fire-rated safes at the Pune HQ, the Hyderabad development centre, and the BCM Manager's and CMT Chair's homes. The contact-tree card was a wallet card, reconciled monthly.
• An External-Origin Document Register listing the ISO standards, the DPDP Act and Rules, the CERT-In Directions, the IRDAI Guidelines, the RBI Master Direction (for the hospital customers), and the hospital-customer contracts, with a source-monitoring owner per document.
• An Evidence-by-Design Framework that captured the exercise, audit, management-review and corrective-action records at the point of origin through the GRC platform's workflow.
• A Protection Regime: access control per document class, confidentiality classification, backup with an immutable copy (RPO of 1 hour for the document set), and the offline copies.

The total investment was approximately ₹52 lakh over the 14-week build (the GRC platform licence and implementation, the offline-copy infrastructure, the fire-rated safes, the BCM Manager's and the team's time, and the external consultant), plus an ongoing annual cost of approximately ₹14 lakh (the GRC platform licence, the annual review, the exercise programme).

The disruption

In the third quarter, a vendor-issued firmware update to the storage array at the Pune primary data centre triggered a cascading failure that took the primary platform down for 31 hours. The platform failed over to the Mumbai DR site, but the failover was incomplete, the patient-records database had a replication lag of 7 minutes, and 7 minutes of patient records (approximately 340 records across 12 hospitals) were not at the DR site. The platform was restored, but the 340 records had to be re-entered from the hospital-side paper backups.

The documented-information response

The CMT convened within 18 minutes of detection, invoking the BC plan from the offline electronic copy on the BCM Manager's laptop. The contact-tree card was current (reconciled 9 days earlier). The IR procedure was retrieved from the offline copy within 3 minutes. The CERT-In notification was made within 4 hours and 20 minutes of detection, inside the 6-hour clock. The DPDP breach-notification assessment (was the 7-minute replication lag a personal-data breach?) was completed within 30 hours, and the decision was made (with Legal) that the missing records were a temporary-availability failure, not a breach, because the data was recoverable from the hospital-side paper backups and was not exfiltrated; the assessment was documented and retained. The customer communication was sent within 2 hours of the failover, with a holding statement from the pre-approved library. The hospital customers were updated hourly during the 31-hour outage. The post-disruption review was conducted within 7 days, and the corrective action (a storage-array firmware-change-control gate and a replication-lag alert) was documented, version-controlled, and tracked to closure.

The ROI

The documented-information regime delivered a measurable return:

• Certification achieved. Aarogya passed the ISO 22301 Stage 2 audit on the first attempt, with zero major nonconformities on Clause 7.5 (and zero overall). The certification retained the largest hospital customer (contract value ₹12 crore per year) and unlocked two new hospital customers (contract value ₹4.5 crore per year). The certification revenue impact: ₹16.5 crore per year, against an investment of ₹52 lakh, a payback period of under 4 months on the certification revenue alone.
• Regulator clocks met. The CERT-In notification was inside the 6-hour clock; the DPDP assessment was documented within the 72-hour clock. The avoided DPDP penalty exposure (up to ₹250 crore for security-safeguards failure, up to ₹200 crore for breach-notification failure) is not a realised saving, but the risk reduction was material.
• Response time reduced. The CMT convened in 18 minutes (the previous year, before the regime, a smaller incident had taken 47 minutes to convene). The IR procedure was retrieved in 3 minutes (the previous year, it had taken 22 minutes to find the plan on the shared drive). The response-time improvement reduced the outage duration, the platform was restored in 31 hours, against an estimated 48 to 60 hours under the previous regime.
• Audit cost reduced. The internal audit and the certification audit were retrieval exercises, not reconstruction projects. The audit preparation effort was 40 person-days (the previous year, it had been 95 person-days). The audit-fee saving was approximately ₹8 lakh.
• Insurance premium reduced. The cyber-insurance underwriter recognised the documented-information regime (the offline copy, the retention schedule, the evidence-by-design framework) and reduced the premium by approximately 12%, saving approximately ₹9 lakh per year.
• Customer trust retained. No hospital customer churned as a result of the outage. The customer-communication discipline (the holding statement, the hourly updates, the post-disruption review shared with the customers) was cited by the largest customer as the reason for retention.

The total quantified annual benefit (certification revenue ₹16.5 crore, audit-cost saving ₹8 lakh, insurance saving ₹9 lakh) was approximately ₹16.67 crore against an annual cost of ₹14 lakh, a return that dwarfed the investment, with the certification revenue as the largest component and the risk-reduction (the avoided DPDP penalty, the avoided customer churn) as the strategic value.

The lessons

• The documented-information regime is not a cost centre; it is a revenue enabler (the certification unlocked customer contracts) and a risk reducer (the regulator clocks were met).
• The offline-copy design was the single most valuable control, the CMT invoked from the offline copy within 18 minutes.
• Evidence by design turned the audit from a reconstruction project into a retrieval exercise.
• The retention schedule, reconciled with every regulatory clock, was the single artefact that satisfied the most regulators at once.
• The investment (₹52 lakh build, ₹14 lakh annual) was modest relative to the certification revenue (₹16.5 crore) and the risk avoided (DPDP penalty exposure).

Multi-Framework Mapping

The following table maps ISO 22301 Clause 7.5 to the most-cited global frameworks and Indian regulatory instruments. Cells with a clause/article/paragraph number are direct cross-references; cells with a name only are methodological analogues.

The densest overlaps

The densest overlaps are with ISO/IEC 27001:2022 Clause 7.5 (identical structure), the CERT-In Directions (the 180-day and 5-year retention clocks), the IRDAI Guidelines (the 180-day log retention), and the DPDP Act (the erasure duty). An Indian organisation that builds one 7.5-conformant documented-information regime satisfies all of these simultaneously, provided the retention schedule reconciles every clock.

Implementation Roadmap

The 7.5 implementation roadmap is phased over 30, 90, 180 days and 12 months, with the critical-path notes for each phase. The roadmap is scaled to a growing company (50 to 250 staff); mid-market and enterprise timelines are longer as noted in section 4.2.

First 30 days, foundation

• Week 1-2: Charter and policy. Charter the documented-information programme with top management. Draft the Documented Information Control Policy. Identify the Document Hierarchy Matrix owner, the Version Control and Change Log owner, the Retention Schedule owner, the External-Origin Register owner.
• Week 2-3: Back-fill the Document Hierarchy Matrix. List every existing BCMS document and record class. Rate each against the seven control dimensions. Identify the gaps.
• Week 3-4: Build the Version Control and Change Log framework. Define the naming convention, the version-numbering scheme, the change-log structure. Apply to the existing documents (back-fill the version history where recoverable).
• Week 4: Build the offline-copy design. Identify the BC plan set. Create the offline electronic copy and the printed copy. Store off-site. Reconcile.
• Critical path: the policy approval (top management) and the offline-copy design (the highest-risk gap in most organisations).

Days 31-90, the control regime

• Month 2: Retention and Disposal Schedule. Build the schedule. Reconcile every Indian regulatory clock (CERT-In 180 days and 5 years; IRDAI 180 days; Companies Act 8 years; DPDP erasure; RBI and SEBI expectations). Define the disposition method and evidence per record class. Define the legal-hold workflow.
• Month 2: External-Origin Document Register. List every external-origin document. Assign a source-monitoring owner per document. Verify the current versions (especially the ISO editions, cite 22300:2021, 22317:2021, 22318:2021, not the withdrawn 2015/2018 editions).
• Month 3: Protection Regime. Define the access control per document class. Define the confidentiality classification. Configure the backup with an offline/immutable copy. Test the restoration.
• Month 3: Format and Media Standard. Define the acceptable formats (PDF/A for long-term), the naming convention, the metadata standard, the print-and-distribute rules.
• Critical path: the Retention Schedule (the most complex artefact) and the Protection Regime (the highest-risk gap after the offline copy).

Days 91-180, the evidence and the discipline

• Month 4: Evidence-by-Design Framework. For each BCMS process, define the records that prove conformity, the point of origin, the metadata, the retention class, the retrieval path.
• Month 4: Procedure and RACI. Finalise the Documented Information Control Procedure. Publish the RACI. Train the document owners.
• Month 5: Review-on-trigger design. Define the triggers (regulatory change, organisational change, post-disruption, exercise, audit, corrective action). Wire the triggers to the review workflow.
• Month 5: First internal audit. Sample ten controlled documents. Walk each end-to-end. Identify the nonconformities. Begin the corrective actions.
• Month 6: First exercise of the offline copy. Run a tabletop that begins with the CMT retrieving the offline copy and invoking from it. Test the contact-tree card. Test the regulator-clock workflow.
• Critical path: the Evidence-by-Design Framework (the difference between an audit-ready and an audit-reconstruction regime) and the first internal audit (the first real test).

Months 7-12, maturity and integration

• Month 7-8: Tooling decision and implementation. If the document set has outgrown the shared-drive regime, select and implement a DMS or GRC platform. Migrate the controlled documents. Enforce the versioning, the access control, the retention policies.
• Month 9: KPI dashboard. Stand up the 13-KPI dashboard. Report to the BCM Steering Committee. Begin the monthly cadence.
• Month 10: Integration with Clause 9.2 and 9.3. Wire the documented-information KPIs into the internal audit and the management review.
• Month 11: Certification audit preparation. Run the retrieval tests. Run the mock audit. Close the corrective actions.
• Month 12: Stage 1 audit. Address the findings. Prepare for Stage 2.
• Critical path: the tooling implementation (if applicable) and the Stage 1 audit (the first external validation).

Beyond 12 months, continual improvement

• Annual review of the Policy, the Procedure, the Document Hierarchy Matrix, the Retention Schedule, the External-Origin Register.
• Quarterly review of the KPI dashboard and the review-on-trigger log.
• Semi-annual backup restoration test.
• Annual exercise of the offline copy and the regulator-clock workflow.
• Maturity advancement per the model in section 22.

FAQ

Q1. Does Clause 7.5 require a document-management system? No. The clause requires documented information to be controlled. A DMS is one way to control it; a well-disciplined shared drive with a controlled naming convention, a change log and a manual retention schedule can satisfy 7.5 at small scale. The choice of tooling is a Clause 7.1 resourcing decision. The break-even for buying a DMS is typically around 100 controlled documents or 100 staff.

Q2. Does 7.5 require the BC plan to be available offline? Yes, in practice. The clause requires documented information to be available where and when it is needed, and adequately protected. For the BC plan, "when it is needed" includes during a disruption, when the primary system may be down. A BC plan that exists only on the system it is designed to recover is not available during the disruption it is designed to manage, and is therefore non-conformant. The offline copy is the standard interpretation.

Q3. How long must we retain BCMS records? It depends on the record class and the applicable regulatory clocks. The minimum baseline for an Indian organisation: ICT logs for 180 days (CERT-In, IRDAI); VPN/cloud/data-centre customer KYC for 5 years (CERT-In); books of account for 8 financial years (Companies Act); personal data until the purpose is served, then erased (DPDP); plus the organisation's BCM needs (exercise reports for the certification cycle, audit reports for at least three cycles, corrective-action records until verified effective). The Retention Schedule reconciles every clock.

Q4. Does the DPDP erasure duty conflict with the CERT-In retention duty? Not if the retention schedule is designed correctly. CERT-In requires retention of ICT logs and KYC for defined periods; DPDP requires erasure of personal data when the purpose is served, unless retention is required by law. The CERT-In retention is a legal requirement that overrides the DPDP erasure for the specified record classes and periods. For personal data not covered by a legal retention requirement, the DPDP erasure duty applies. The legal-hold workflow handles the override for litigation or regulatory inquiry. The Retention Schedule documents the reconciliation.

Q5. Can we keep superseded versions of the BC plan? You must. Superseded versions are the evidence of "which version was in force when", the question an auditor or a regulator asks after an incident. Deleting superseded versions is a non-conformity and a legal-discovery risk. They are archived for the retention period, then disposed of securely.

Q6. Do we need to control documents of external origin? Yes. The clause requires control of distribution and updating of external-origin documents. The External-Origin Document Register is the control artefact. This is particularly important for regulator circulars and ISO standards, citing a withdrawn ISO edition (e.g., ISO/TS 22317:2015 instead of the current 2021 edition, or ISO 22300:2018 instead of the current 2021 edition) is a non-conformity.

Q7. Is "keep everything forever" a valid retention policy? No. The clause requires retention and disposition to be managed. "Keep everything forever" is the absence of a management decision. It also fails the DPDP erasure duty, and it creates unbounded storage cost and legal-discovery risk. The Retention Schedule must define a retention period for each record class, and disposition must be executed and evidenced.

Q8. Does 7.5 require a single approver for all documents? No. The approval authority is defined per document tier in the Document Hierarchy Matrix. Tier 1 documents (policy, scope, objectives) are approved by top management. Tier 2 (BIA, strategies, procedures) by the BCM Steering Committee. Tier 3 (operational plans) by the plan owner. Tier 4 records are captured at the point of origin without a separate approval. The tiered model is the right design for most growing companies.

Q9. How do we handle personal data in BCMS records (BIA interview notes, exercise participant lists, incident reports)? Identify the personal-data record classes in the Retention Schedule. Apply the DPDP erasure duty: retain for the purpose (the BCM need or the legal requirement), then erase. Apply confidentiality classification (these are Confidential or Restricted). Apply access control (need-to-know). Capture the erasure evidence when disposed.

Q10. Does 7.5 apply to paper documents? Yes. The clause is media-neutral. Paper documents are documented information. The Format and Media Standard defines the print-and-distribute rules. Paper documents must be version-controlled (the version and date on the face), access-controlled (locked cabinets, access-controlled rooms), physically protected (fire-rated safes for the most critical), and retained and disposed of per the schedule (cross-cut shredding or controlled incineration).

Q11. How often should we review the BC plan? At minimum annually, and on trigger. The triggers: regulatory change, organisational change (a new site, a new product, a new critical supplier), post-disruption review, exercise outcome (the exercise revealed a plan defect), audit finding, and corrective action. The review-on-trigger is documented.

Q12. What is the single most important 7.5 control? The offline copy of the BC plan set. If the plans are not available during a disruption, every other control is academic. The offline copy is the precondition for the BCMS to function on the worst day.

Q13. Does 7.5 require evidence by design? The clause requires documented information to be controlled, and the standard requires the organisation to retain documented information as evidence of conformity. Evidence by design, capturing the records at the point of origin, is the most reliable way to satisfy this. Reconstruction after the fact is weaker evidence and a common audit failure.

Q14. Can we use a collaboration platform with versioning as our DMS? For a small organisation, yes, provided the retention and disposition discipline is enforced through policy and procedure. For a regulated mid-market or enterprise entity, a collaboration platform is usually not sufficient, it lacks the records-management, legal-hold and disposition-evidence capabilities. The decision is a Clause 7.1 resourcing decision.

Q15. What is the cost of a 7.5-conformant regime for a growing company? The build cost for a 200-person company is typically ₹15 to ₹40 lakh (tooling, implementation, the BCM Manager's and the team's time, and external consulting), plus an ongoing annual cost of ₹6 to ₹14 lakh (tooling licence, annual review, exercise). The cost is modest relative to the certification revenue it enables and the regulatory penalty it avoids.

Industry-Specific Requirements

BFSI (banks, NBFCs, payment system operators, insurers)

The most documentation-heavy sector. The RBI Master Direction on IT Governance (7 November 2023, effective 1 April 2024) requires a board-approved BCP/DR policy, documented RTO/RPO for critical systems, documented critical-systems classification, DRS architecture documentation, BCP drill records, third-party continuity documentation and IT-readiness documentation. The RBI Cyber Security Framework (2 June 2016) requires a board-approved cyber-security policy, CCMP documentation, incident-reporting records (2 to 6 hours), and drill records. The SEBI CSCRF (20 August 2024) and the SEBI MII BCP-DR (22 March 2021) require documented recovery architecture, drill records, board-approval records and 6-hour incident-reporting records. The IRDAI Information and Cyber Security Guidelines (24 April 2023) require a board-approved Information and Cyber Security Policy including BCP/DR, 180-day log retention, DR drill records, ICT-outsourcing documentation and annual compliance reporting. CERT-In requires 180-day ICT logs and 5-year KYC. The retention schedule is the most complex; the BC plan set is the most extensive; the regulator oversight is the highest. The offline copy is non-negotiable, a bank whose BC plan is on the encrypted core banking server has failed 7.5 and the RBI's supervisory expectation simultaneously.

Healthcare

Patient-safety documentation, clinical-continuity procedures, the e-Hospital or HIS system documentation, the patient-data retention under DPDP (likely as a Significant Data Fiduciary). The AIIMS Delhi 2022 ransomware (primary and backup servers encrypted together, e-Hospital down for days, OPD/admissions/billing/labs reverted to paper) is the cautionary tale, the documented recovery procedures and the documented backup regime did not survive the disruption. The offline copy of the clinical-continuity procedures, the manual-workaround procedures (paper-based OPD, billing, prescription), and the contact tree for the clinical and IT leadership are the BCM-critical documentation. Patient records are personal data under DPDP; the retention schedule must reconcile the clinical-record retention (per the hospital policy and the Clinical Establishments Act) with the DPDP erasure duty.

IT/ITeS and SaaS

The BCP/DR documentation for client-facing services, the SLA documentation, the incident-response documentation, the data-locality documentation. Where serving EU financial clients, DORA documentation requirements apply (Article 6(5) framework documentation, Article 11(1) ICT BCP, Article 11(5) BIA, Article 12 backup, Article 28 register of information). The customer contracts typically include audit-rights and documentation clauses; the BCMS documentation must be customer-audit-ready. The retention schedule must reconcile the customer-contract retention (often 10 years for regulated customer data) with the DPDP and CERT-In clocks. The evidence-by-design framework is particularly valuable, the SaaS platform's workflow can capture much of the BCMS evidence automatically.

Manufacturing (especially chemical and pharma)

The on-site and off-site emergency plans under the NDMA Chemical Disaster Guidelines (2007), the MAH (Major Accident Hazard) documentation, the OT/IT segmentation documentation. The LG Polymers Vizag 2020 styrene gas leak (NGT interim penalty of ₹50 crore, 12 to 13 fatalities, the plant permanently closed) is the cautionary tale, the documented emergency procedures were inadequate. The Maruti Suzuki Manesar 2012 violence (a workplace-violence disruption scenario, approximately ₹1,400 crore lockout loss) is a reminder that BCMS documentation must cover workplace-violence and industrial-relations scenarios, not only fire, flood and cyber. The documented emergency procedures must be available at the assembly line (printed, posted, in the local language), not only on a portal. The retention schedule must reconcile the environmental and safety records (long retention under the Factories Act and the Environmental Laws) with the BCM needs.

Government and public sector

The Disaster Management Plan documentation under DM Act 2005 Section 40, the NDMA DMP template (Prevention / Mitigation / Preparedness / Response / Relief / Recovery and Reconstruction / Capacity Building), the integration with District DMPs, the e-governance documentation under IT Act Section 84A. The documented information must be available in the local language and accessible to the field workforce. The retention schedule must reconcile the public-records retention (often long, per the Public Records Act and the state equivalents) with the BCM needs. The CERT-In directions apply to government ICT systems. The NCIIPC documentation obligations apply where the system is a protected system.

Maturity Model

The 7.5 maturity model has five levels, with INR investment estimates for a growing company (50 to 250 staff). The estimates are illustrative; actual costs vary with the organisation's size, complexity and starting point.

Level 1, Initial (ad hoc)

The BCMS documentation is a folder of files on a shared drive. There is no Document Hierarchy Matrix, no Version Control and Change Log, no Retention Schedule, no External-Origin Register, no offline copy. The version control is the filename. The protection is shared-drive permissions. The backup is "the IT team does something". The retention is "we keep everything forever". When the shared drive is encrypted, the BC plans are lost. The regime is non-conformant by construction.

• Investment to reach L2: ₹6 to ₹12 lakh (the policy, the procedure, the Document Hierarchy Matrix back-fill, the Version Control framework, the Retention Schedule, the offline-copy design, the first internal audit, the BCM Manager's and the team's time, light external consulting).
• Typical Indian growing-company position: approximately 60% of growing companies are at L1.

Level 2, Managed (documented)

The BCMS documentation is documented. The Documented Information Control Policy is board-approved. The Document Hierarchy Matrix exists. The Version Control and Change Log is maintained (manually or on a shared drive). The Retention Schedule reconciles the main regulatory clocks (CERT-In, IRDAI, DPDP, Companies Act). The offline copy of the BC plan set exists. The External-Origin Document Register exists. The protection regime includes access control and backup. The first internal audit has been run. The regime is auditable but manual; the discipline depends on the BCM Manager.

• Investment to reach L3: ₹12 to ₹25 lakh (a DMS or a mid-market GRC platform, the implementation, the migration, the evidence-by-design framework, the review-on-trigger workflow, the KPI dashboard, the training, the first certification cycle).
• Typical Indian growing-company position: approximately 25% of growing companies are at L2.

Level 3, Defined (integrated)

The BCMS documentation is integrated with a DMS or GRC platform. The version control is enforced by the platform. The retention policies are enforced automatically, with legal-hold workflow. The access control is granular per document class. The evidence is captured at the point of origin (evidence by design). The KPI dashboard is operational. The review-on-trigger is wired to the workflow. The offline copy is reconciled at every version change. The external-origin documents are monitored. The regime is auditable and scalable; the discipline is platform-supported, not person-dependent.

• Investment to reach L4: ₹15 to ₹35 lakh (the GRC platform advanced configuration, the records-management module, the integration with the ITSM and the collaboration platform, the advanced protection regime with immutable backup, the maturity-advancement exercises).
• Typical Indian growing-company position: approximately 10% of growing companies are at L3.

Level 4, Quantitatively managed (measured)

The BCMS documentation is measured. The 13 KPIs are tracked, trended, and reported to the BCM Steering Committee, the Risk Management Committee and the board. The retrieval test is run in every internal audit, with a target time. The backup restoration test is run semi-annually, with a pass/fail. The review-on-trigger response time is measured. The disposition execution rate and the disposition evidence rate are tracked. The regime is not only auditable but measurably improving.

• Investment to reach L5: ₹10 to ₹25 lakh (the analytics, the automation, the advanced exercising, the continual-improvement programme, the multi-entity integration if applicable).
• Typical Indian growing-company position: approximately 4% of growing companies are at L4.

Level 5, Optimising (continually improving)

The BCMS documentation is continually improving. The KPIs trend to target and are maintained. The regime is benchmarked against external practice. The lessons from exercises, audits, disruptions and corrective actions are systematically fed back into the documentation. The organisation contributes to the practice (industry forums, regulator consultations). The regime is not only conformant but a competitive edge, the documentation is a strategic asset, not a compliance overhead.

• Sustaining investment: ₹6 to ₹14 lakh per year (the platform licence, the annual review, the exercise programme, the maturity-advancement plan).
• Typical Indian growing-company position: approximately 1% of growing companies are at L5.

The maturity-advancement path

The path from L1 to L3 is the most consequential, it is the path from non-conformant to certifiable. The path from L3 to L5 is the path from certifiable to strategic. Most growing companies should target L3 as the minimum for certification and L4 as the target for the second certification cycle. The investment is modest relative to the certification revenue and the regulatory risk avoided, the Aarogya HealthTech illustrative scenario in section 15 shows a ₹52 lakh build against a ₹16.5 crore certification-revenue impact.

Emerging Trends

The DPDP Rules 2025 and the erasure-by-default shift

The DPDP Rules 2025 (final notified November 2025) operationalise the DPDP Act's erasure duty. For BCMS documentation containing personal data, this shifts the default from "retain indefinitely" to "erase when the purpose is served". The Retention Schedule must be DPDP-aware, personal-data record classes identified, the erasure workflow defined, the erasure evidence captured. The legal-hold workflow is the override. This is the most significant emerging trend for 7.5 in the Indian context, the reconciliation of the BCM need-to-retain with the DPDP duty-to-erase.

Immutable and air-gapped backup for documentation

The AIIMS failure pattern (primary and backup encrypted together) has driven the adoption of immutable and air-gapped backup for the most critical documentation. An immutable backup cannot be modified or deleted within the retention period, even by an administrator, it is ransomware-resistant. An air-gapped copy is physically or logically isolated from the primary network. The 3-2-1 rule is evolving to 3-2-1-1-0 (three copies, two media, one off-site, one offline or immutable, zero errors). For the BC plan set, this is becoming the expected standard, not the advanced practice.

Evidence by design and the audit-ready regime

The shift from reconstruction-after-the-fact to evidence-by-design is accelerating, driven by the GRC platforms' workflow capabilities and by the regulators' increasing expectation of real-time evidence. An evidence-by-design regime captures the records at the point of origin, the exercise report is generated by the exercise workflow, the audit finding by the audit workflow, the corrective action by the corrective-action workflow. The audit becomes a retrieval exercise, not a reconstruction project. This is the most consequential operational trend for 7.5.

The climate-change adaptation dimension (Amendment 1:2024)

ISO 22301:2019 Amendment 1:2024 added climate-change adaptation to Clauses 4.1 and 4.2. The documentation implication is that the context analysis and the interested-party analysis must document climate-related issues and stakeholders. This is a 4.1/4.2 change, but it flows into 7.5, the documented context must reflect the climate dimension, and the BIA and the strategies must account for climate-related disruption scenarios.

The DORA documentation regime for EU-exposed Indian firms

For Indian IT/BPO/SaaS firms serving EU financial clients, DORA (applicable from 17 January 2025) imposes a documentation regime that overlays the ISO 22301 7.5 regime. The DORA documentation, the ICT risk framework (Article 6(5)), the ICT BCP (Article 11(1)), the BIA (Article 11(5)), the backup policies (Article 12), the register of information on ICT third-party arrangements (Article 28), is documented information under 7.5 control. The Retention Schedule must reconcile the DORA expectations with the Indian clocks.

The convergence of BCM and operational resilience

The global shift from "business continuity" to "operational resilience" (DORA, APRA CPS 230, the UK operational-resilience regime, HKMA OR-2) is changing the documentation expectations. Operational resilience requires documentation of the important business services, the end-to-end mapping, the impact tolerances, the severe-but-plausible scenarios, and the lessons learned, a richer documentation set than the traditional BC plan. The 7.5 regime must accommodate this richer set; the Document Hierarchy Matrix must include the operational-resilience artefacts.

The AI-assisted document-control regime

Emerging practice uses AI-assisted tools for document classification, retention-policy enforcement, metadata extraction, and anomaly detection (e.g., detecting uncontrolled documents on the shared drive). This is an emerging capability, not a current requirement; the clause is satisfied by the discipline, not by the technology. But for large document sets, the AI-assisted regime is becoming cost-effective. The evaluation is by capability, not by brand; the data-residency and the DPDP implications must be assessed before adoption.

References and Further Reading

The following are the primary sources and recognised references for this guide. Standards are paywalled; cite the current edition and verify against the official PDF before quoting verbatim. The official ISO 22301:2019 clause text is copyrighted and is not reproduced in this guide; the sanctioned requirement statement is the own-words paraphrase from the standard's manifest, attributed as "ISO 22301 Clause 7.5 asks organizations to create, update, and control the documented information the BCMS requires."

Standards and companion guidance

• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements (second edition; with Amendment 1:2024 on climate-change adaptation).
• ISO 22313:2020, Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
• ISO 22300:2021, Security and resilience, Vocabulary (third edition; a fourth edition is under development (ISO/DIS 22300, 4th ed.) and not yet published, verify on iso.org).
• ISO/TS 22317:2021, Security and resilience, Business continuity management systems, Guidelines for business impact analysis (second edition; the 2015 edition is withdrawn).
• ISO/TS 22331:2018, Security and resilience, Business continuity management systems, Guidelines for business continuity strategy. (Note: ISO catalogue page iso.org/standard/50068.html lists this as ISO/TS 22331:2018; year requires confirmation.)
• ISO/TS 22318:2021, Business continuity management systems, Guidelines for supply chain continuity (second edition; the 2015 edition is withdrawn).
• ISO/TS 22330:2018, Security and resilience, Guidelines for people resilience.
• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements (Clause 7.5 and Annex A controls 5.29, 5.30, 5.12, 5.33, 5.34, 8.10, 8.13, 8.14).
• ISO/IEC 27031:2011, Guidelines for information and communication technology readiness for business continuity.
• ISO 15489-1:2016, Information and documentation, Records management.
• ISO 9001:2015, Quality management systems, Requirements (Clause 7.5).

Global frameworks and regulations

• NIST SP 800-34 Rev 1 (May 2010), Contingency Planning Guide for Federal Information Systems.
• NIST SP 800-88 Rev 1, Guidelines for Media Sanitization.
• NIST CSF 2.0 (26 February 2024), The NIST Cybersecurity Framework 2.0 (Recover function).
• FFIEC IT Examination Handbook, Business Continuity Management Booklet (November 2019; OCC Bulletin 2019-57, FRB SR 19-13, FDIC FIL-19071-2019).
• Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA; applies from 17 January 2025).
• APRA Prudential Standard CPS 230, Operational Risk Management (effective 1 July 2025; paragraphs 40, 43).
• MAS Technology Risk Management Guidelines (18 January 2021).
• HKMA Supervisory Policy Manual TM-G-2 (31 May 2022) and OR-2 (31 May 2022).
• SOC 2 Trust Services Criteria (Availability, Confidentiality).

Indian regulatory instruments

• RBI Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (7 November 2023, effective 1 April 2024).
• RBI Cyber Security Framework in Banks (2 June 2016).
• RBI Master Directions on Outsourcing of Information Technology Services (10 April 2023).
• SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (20 August 2024; SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113).
• SEBI Guidelines for BCP and DR of Market Infrastructure Institutions (22 March 2021; SEBI/HO/MRD1/DTCS/CIR/P/2021/33).
• IRDAI Information and Cyber Security Guidelines, 2023 (24 April 2023).
• CERT-In Directions under Section 70B(6) of the IT Act, 2000 (28 April 2022; No. 20(3)/2022-CERT-In), 180-day ICT log retention, 5-year KYC/customer data retention, 6-hour incident reporting.
• Digital Personal Data Protection Act, 2023 (Act 22 of 2023; Section 8(5) availability, Section 8(6) breach notification).
• Digital Personal Data Protection Rules, 2025 (final notified November 2025, re-confirm the exact notification date against the MeitY gazette).
• Companies Act, 2013 (Section 134(3)(n), Section 177; 8-year book retention).
• Information Technology Act, 2000 (Sections 43, 65, 70A, 70B, 72, 84A).
• Disaster Management Act, 2005 (Act 53 of 2005; Section 40 DMP).
• NDMA National Disaster Management Guidelines, Chemical Disasters (Industrial), 2007.

Incident anchors (primary-sourced, used for the illustrative scenarios)

• AIIMS Delhi ransomware (23 November 2022), peer-reviewed IJIM illustrative scenario; thehindu.com (NIA takeover). Documented-information failure: primary and backup servers encrypted together.
• HDFC Bank RBI action (2 December 2020), RBI order; finextra.com; livemint.com. Documented-information failure: regulator treated repeated outages as governance/documentation failure.
• Cognizant Maze ransomware (18-20 April 2020), SEC-filed 10-Q/10-K; Q2 2020 impact US$50 to 70 million. Documented-information failure: insufficient segmentation, recovery documentation inadequate.
• Cognizant Chennai floods (December 2015), Cognizant official statement; reaffirmed FY2015 revenue guidance of at least US$12.41 billion. Documented-information success: BCP invoked, staff relocated, guidance held.
• Akasa Air CrowdStrike outage (19 July 2024), zero flight cancellations, manual booking/check-in. Documented-information success: manual-workaround procedures available and exercised.
• LG Polymers Vizag styrene gas leak (7 May 2020), NGT interim penalty of ₹50 crore (OA 73/2020). Documented-information failure: emergency procedures inadequate.

Recognised professional disciplines (citable, not quoted)

• Records management practice under ISO 15489.
• Information governance and digital preservation practice.
• Recognised BCM professional practices and certification curricula (BCI and DRI certifications are recognised credentials in the Indian market).
• CERT-In advisories and the CERT-In PoC network.
• NDMA Do's-and-Don'ts public-communication material (ndma.gov.in).

Singahi, the ISO 22301 specialists for growing companies in India.