ISO 27001 A.5.31: Legal, Statutory, Regulatory and Contractual Requirements

Quick Reference: A.5.31 in 60 Seconds

What the Standard Actually Requires

Figure · Process

What A.5.31 asks you to do

ISO 27001:2022 A.5.31 Text

ISO 27001:2022 Annex A 5.31 asks organizations to identify, document, and keep current the legal, statutory, regulatory, and contractual requirements relevant to information security.

That single sentence is deceptively simple. It hides an enterprise-grade obligation: every law, regulation, contractual clause, industry standard, and statutory order that touches information security must be explicitly identified, written down, assigned, reviewed, and used to shape the ISMS.

ISO 27002:2022 Implementation Guidance (Section 5.31)

ISO 27002:2022 expands A.5.31 into six practical implementation guidelines:

1. Identify all relevant requirements, The organization should identify legal, statutory, regulatory, and contractual requirements that relate to information security. This includes data protection laws, sector-specific regulations, cybercrime laws, export control regulations, intellectual property laws, employment laws, and contractual obligations to customers, suppliers, and partners.

2. Document the requirements, Each requirement should be documented in a manner that allows the organization to determine how it applies, who is responsible for compliance, and what evidence is needed. Documentation should be accessible to relevant personnel.

3. Keep requirements up to date, The organization should establish a process to monitor changes in legal, regulatory, and contractual requirements and update the register accordingly. Triggers include new legislation, amendments, court judgments, regulator circulars, and new contracts.

4. Integrate into the ISMS, Identified requirements should be reflected in policies, procedures, risk assessments, control objectives, and operational processes. Compliance should be planned, implemented, monitored, and improved.

5. Assign responsibilities, Responsibilities for identifying, interpreting, implementing, and monitoring compliance should be assigned and communicated.

6. Review at planned intervals, The register and compliance status should be reviewed at planned intervals (typically annually) and when significant changes occur.

Shall / Should / Analysis

What Auditors Actually Check

Why This Control Matters

The Business Risk Narrative

Organizations today operate inside a tightening web of obligations. A single overlooked contractual clause can overhead a major enterprise customer. A missed regulatory amendment can trigger penalties. A forgotten statutory reporting deadline can escalate into a criminal complaint. A.5.31 is the control that prevents these failures by forcing the organization to know, document, and act on every information security-related obligation.

Without A.5.31, compliance is reactive. With A.5.31, compliance becomes a managed, measurable, improvable system.

The Indian Regulatory Context

India has one of the most dynamic and expanding digital regulatory frameworks in the world. Organizations cannot claim ISO 27001 certification credibility without demonstrating awareness of the following:

Digital Personal Data Protection Act, 2023 (DPDP Act)

India's first complete data protection law imposes obligations on Data Fiduciaries and Significant Data Fiduciaries:

• Lawful processing (Section 4): Consent, legitimate uses, and deemed consent.
• Notice requirements (Section 5): Granular notice at the time of data collection.
• Data Principal rights (Section 12–14): Access, correction, erasure, grievance redressal.
• Data Protection Officer (Section 10): Appointment for Significant Data Fiduciaries.
• Data Fiduciary duties (Section 8): Reasonable security safeguards and breach notification.
• Breach notification (Section 9): Inform the Board and affected Data Principals.
• Penalties (Section 33): Up to for failure to implement reasonable security safeguards.

A.5.31 requires organizations to document these obligations, assign owners, and integrate them into the ISMS.

Information Technology Act, 2000 (IT Act 2000)

• Section 43A: Compensation for failure to protect sensitive personal data or information (SPDI).
• Section 66C: Punishment for identity theft.
• Section 66D: Punishment for cheating by personation using computer resources.
• Section 66E: Punishment for violation of privacy.
• Section 72A: Punishment for disclosure of information in breach of lawful contract.
• Section 69: Powers to issue directions for interception, monitoring, or decryption.
• Section 70B: Powers of the Indian Computer Emergency Response Team (CERT-In).

CERT-In Directions, 2022

The Indian Computer Emergency Response Team (CERT-In) issued mandatory directions effective 27 June 2022:

• Synchronous logs: Maintain logs of ICT systems for 180 days within Indian jurisdiction.
• Incident reporting: Report cyber incidents within 6 hours of noticing or being notified.
• KYC and contact data: Maintain accurate KYC records and 24×7 contact points.
• VPN and cloud registration: Data centres, VPS providers, cloud service providers, and VPN providers must retain user data for 5 years.
• Cryptocurrency exchanges: Maintain KYC and transaction records for 5 years.

Failure to comply can result in imprisonment up to 1 year or fine up to under Section 70B(7).

Reserve Bank of India (RBI) Regulations

For banks, NBFCs, payment system operators, and fintechs:

• Master Direction on Information Technology Framework for the NBFC Sector.
• Cyber Security Framework in Banks.
• Guidelines on Information Security, Electronic Banking, Technology Risk Management, and Cyber Frauds.
• Master Direction on Digital Payment Security Controls.
• Mandatory reporting of cyber incidents to RBI within 2–6 hours depending on severity.

Securities and Exchange Board of India (SEBI)

For stock brokers, depository participants, mutual funds, and market infrastructure institutions:

• SEBI Circular CIR/MRD/DP/13/2015 on cyber security and cyber resilience.
• SEBI Master Circular SEBI/HO/MIRSD/MIRSD-PoD-1/P/CIR/2023/70 on cyber security.
• Requirements for annual cyber audit, CISO appointment, incident reporting, and vendor due diligence.

Insurance Regulatory and Development Authority of India (IRDAI)

• IRDAI (Information and Cyber Security) Guidelines, 2017.
• IRDAI Master Circular on Information and Cyber Security for Insurers.
• Requirements for governance, risk assessment, incident reporting, third-party management, and business continuity.

Telecom Regulatory Authority of India (TRAI)

For telecom and internet service providers:

• Telecom Commercial Communications Customer Preference Regulations.
• Quality of Service Regulation on Data Speed and Wireless Network Coverage.
• Data localization and lawful interception obligations.

Other Key Indian Laws

• Indian Contract Act, 1872: Governs contractual obligations.
• Copyright Act, 1957: Protects software and content.
• Patents Act, 1970: Protects inventions and algorithms.
• Trade Marks Act, 1999: Protects brand identity.
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011.
• Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021.
• Companies Act, 2013: Board responsibilities, secretarial standards, record keeping.
• Consumer Protection Act, 2019: E-commerce rules and data protection.
• Prevention of Money Laundering Act, 2002: KYC and record retention.

Industry-Specific Consequences

impact of Non-Compliance with Statistics

• IBM impact of a Data Breach Report 2024: India had the highest average data breach overhead in the region at per breach. Regulatory fines and legal overhead are a major component.
• DPDP Act penalties: Up to for failure to implement reasonable security safeguards (Section 33).
• CERT-In non-compliance: Imprisonment up to 1 year or fine up to .
• RBI penalties: Range from to depending on the severity and recurrence.
• SEBI penalties: Up to or three times the profits made, whichever is higher.
• Customer contract damages: Enterprise SaaS contracts often include liquidated damages of 10–30% of annual contract value for security breaches.
• Reputational overhead: Indian B2B buyers increasingly require ISO 27001, SOC 2, and DPDP readiness before procurement. Losing a major enterprise tender can overhead crores.

Scope and Applicability

What A.5.31 Covers

A.5.31 covers every legal, statutory, regulatory, and contractual requirement that has a bearing on information security. This includes:

• Statutory laws passed by Parliament or state legislatures (e.g., IT Act 2000, DPDP Act 2023, Indian Penal Code provisions on data theft).
• Subordinate legislation such as rules, regulations, directions, circulars, and notifications (e.g., CERT-In Directions 2022, SPDI Rules 2011).
• Regulatory guidelines issued by sectoral regulators (RBI, SEBI, IRDAI, TRAI, RBI).
• International laws that apply due to cross-border operations or customer locations (e.g., GDPR for EU data subjects, CCPA for California residents, PDPA for Singapore residents).
• Contractual obligations in customer agreements, vendor contracts, NDAs, SLAs, DPAs, MSAs, order forms, and statements of work.
• Industry standards that have contractual or regulatory force (PCI DSS for card data, ISO 27017/27018 for cloud, ISO 27701 for privacy).
• Internal policies and commitments that create enforceable obligations (e.g., public privacy notices, security whitepapers, SOC 2 commitments).

Who It Applies To

A.5.31 applies to the entire organization and its extended enterprise:

• All employees: Must know and comply with relevant policies derived from legal/contractual obligations.
• Contractors and consultants: Subject to contractual security clauses and statutory duties.
• Third-party suppliers and processors: Must meet security obligations flowing down from the organization's legal and contractual requirements.
• Subsidiaries and affiliates: Must comply with group-level legal and compliance register.
• Cloud and offshore partners: Must respect data localization, cross-border transfer, and incident reporting obligations.

Role Categories Affected

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

A.5.31 is a horizontal governance control that feeds information into many other Annex A controls.

Upstream Controls (Inputs to A.5.31)

Downstream Controls (Outputs from A.5.31)

Parallel Controls

Detailed Implementation Guidance

Phase 1: Establish Governance

Step 1.1: Define the Compliance Operating Model

Before building a register, decide who does what. The recommended model for Indian organizations is:

┌─────────────────────────────────────────────────────────────────────┐
│  BOARD / TOP MANAGEMENT                                               │
│  • Approve compliance strategy and risk appetite                      │
│  • Review compliance status at management review                      │
└─────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  COMPLIANCE COMMITTEE (Quarterly)                                     │
│  • CISO, General Counsel, DPO, Risk Manager, HR Head, IT Director     │
│  • Reviews register, escalations, and regulatory changes              │
└─────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  LEGAL AND COMPLIANCE REGISTER OWNER                                  │
│  • Compliance Officer / DPO / CISO (depending on org structure)       │
│  • Maintains the register, coordinates reviews, reports metrics       │
└─────────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────────┐
│  REQUIREMENT OWNERS (Per law / contract / clause)                     │
│  • Legal: Statutory and regulatory interpretation                     │
│  • CISO: Security control implementation                              │
│  • DPO: Privacy and data protection obligations                       │
│  • Procurement: Supplier contractual obligations                      │
│  • Sales: Customer contractual obligations                            │
│  • HR: Employment law and training obligations                        │
│  • IT/Engineering: Technical implementation                           │
└─────────────────────────────────────────────────────────────────────┘

Step 1.2: Issue a Compliance Policy

See Section 9 for the full Compliance and Legal Requirements Policy template. At minimum, the policy must define:

• Purpose and scope
• Definitions
• Responsibilities
• Register structure and maintenance
• Review frequency
• Change management triggers
• Escalation and non-compliance handling
• Integration with ISMS

Phase 2: Identify Requirements

Step 2.1: Map the Internal Landscape

Before searching externally, understand what the organization already knows:

Step 2.2: Build the Legal and Regulatory Universe

For an Indian B2B tech organization, the legal universe typically includes:

National Cyber and Data Laws

• Information Technology Act, 2000
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011
• Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021
• Digital Personal Data Protection Act, 2023
• CERT-In Directions, 2022
• Indian Telegraph Act, 1885 (for telecom interception)
• Indian Penal Code, 1860 (relevant sections on theft, cheating, criminal breach of trust)

Sectoral Regulations

• RBI Master Directions on IT and Cyber Security
• SEBI Cyber Security and Cyber Resilience Circulars
• IRDAI Information and Cyber Security Guidelines
• TRAI Directions and QoS Regulations
• National Health Authority / ICMR data guidelines

Commercial and IP Laws

• Indian Contract Act, 1872
• Copyright Act, 1957
• Patents Act, 1970
• Trade Marks Act, 1999
• Designs Act, 2000
• Companies Act, 2013
• Competition Act, 2002

Employment and Labour Laws

• Industrial Employment (Standing Orders) Act, 1946
• Shops and Establishments Acts (state-specific)
• Sexual Harassment of Women at Workplace Act, 2013
• Contract Labour Act, 1970

Consumer and e-Commerce

• Consumer Protection Act, 2019
• Consumer Protection (E-Commerce) Rules, 2020

Financial Crime

• Prevention of Money Laundering Act, 2002
• Prevention of Money Laundering (Maintenance of Records) Rules, 2005

International Applicability

• GDPR (if EU data subjects)
• UK GDPR / Data Protection Act 2018
• CCPA / CPRA (if California residents)
• Singapore PDPA
• UAE PDPL
• Saudi Arabia PDPL
• Any other jurisdiction where customers or users are located

Step 2.3: Extract Contractual Requirements

For each significant customer contract, extract:

Phase 3: Document the Register

Step 3.1: Register Structure

The Legal and Compliance Register should contain the following columns:

Step 3.2: Sample Register Entries

Phase 4: Integrate into the ISMS

Step 4.1: Translate Obligations into Policies

Every high-risk obligation should be traceable to at least one policy or procedure. Examples:

Step 4.2: Embed in Risk Assessment

Legal and regulatory non-compliance should be treated as a risk scenario in the enterprise risk register:

• Risk: Failure to comply with DPDP Act 2023 leading to penalty and customer churn.
• Likelihood: Medium (new law, evolving guidance).
• Impact: Very High (up to , reputational damage).
• Risk Level: High.
• Treatment: Implement privacy program, appoint DPO, conduct DPIA, update consent flows, train staff.

Step 4.3: Trigger Change Management

New laws, regulations, or contracts must trigger the change management process:

Phase 5: Maintain and Review

Step 5.1: Regulatory Intelligence

Set up a regulatory intelligence process:

• Sources: Official gazettes, regulator websites, legal news (Live Law, SCC Online, Bar and Bench), industry associations (NASSCOM, DSCI), law firm newsletters, compliance tools.
• Frequency: Daily automated alerts; weekly manual scan; monthly summary.
• Owner: Legal Counsel or external compliance retainer.

Step 5.2: Review Cadence

Step 5.3: Version Control and Evidence

• Maintain version history of the register.
• Store evidence centrally (document management system, GRC tool, or secure shared drive).
• Link evidence to register entries.
• Protect evidence integrity (read-only storage, access logs).

Sector-Specific Implementation Notes

A.5.31 is universal in principle but highly specific in practice. The legal and contractual universe of a payment fintech differs dramatically from that of a hospital SaaS provider or an e-commerce marketplace. Below are implementation notes for major Indian B2B sectors.

Banking, Financial Services, and Insurance (BFSI)

BFSI organizations face the densest regulatory environment. The register must include:

• RBI: Master Direction on IT Framework, Cyber Security Framework in Banks, Digital Payment Security Controls, incident reporting timelines (2–6 hours depending on severity), annual cyber audit, CISO appointment, vendor risk management.
• SEBI: Cyber security and cyber resilience circulars for market infrastructure institutions, brokers, depositories, and mutual funds.
• IRDAI: Information and Cyber Security Guidelines for insurers, including governance, risk assessment, third-party management, and business continuity.
• NPCI: UPI, RuPay, and IMPS operating guidelines.
• PCI DSS: Mandatory for card data processing.
• Contracts: Enterprise customers demand SOC 2 Type II, ISO 27001, encryption, audit rights, and strict breach notification.

Implementation tip: Use a GRC platform with pre-built RBI and SEBI content. Appoint a dedicated regulatory intelligence owner who scans regulator websites weekly. Run quarterly mock incident reporting drills to ensure CERT-In and RBI timelines are met.

SaaS and Cloud Technology

SaaS companies typically face a contract-heavy compliance universe rather than a regulator-heavy one. The register must capture:

• DPDP Act 2023: Consent, notice, Data Principal rights, breach notification, cross-border transfers, Significant Data Fiduciary designation risk.
• Customer contracts: Each enterprise MSA, DPA, and order form may contain unique security clauses, audit rights, data residency, and subprocessor restrictions.
• GDPR / UK GDPR / CCPA: If serving global customers or end-users.
• CERT-In Directions 2022: Log retention and incident reporting.
• Cloud-specific standards: ISO 27017, ISO 27018, CSA STAR, SOC 2.

Implementation tip: Build a "Customer Compliance Register" separate from the legal register. Integrate contract review into the CRM/quote-to-cash workflow so security clauses are extracted before signature, not after.

Healthtech and Healthcare

Healthtech companies handle sensitive health data and must navigate:

• DPDP Act 2023: Sensitive personal data including health data.
• SPDI Rules 2011: Reasonable security practices for sensitive personal data.
• ICMR National Ethical Guidelines for Biomedical and Health Research Involving Human Participants: For research data.
• Clinical Establishments Act and state-specific regulations: For patient records.
• IRDAI guidelines: If integrating with insurers.
• Customer hospitals: Often impose HIPAA-like obligations through contracts.
• Telemedicine Guidelines 2020: Data protection and retention for teleconsultation platforms.

Implementation tip: Conduct a Data Protection Impact Assessment (DPIA) for all health data processing. Ensure encryption, access logging, and retention schedules meet both legal and contractual hospital requirements.

E-commerce and Retail

E-commerce platforms must track:

• Consumer Protection Act 2019 and E-Commerce Rules 2020: Data protection, grievance redressal, and seller information.
• DPDP Act 2023: Consent and notice for customer data.
• Payment Card Industry (PCI DSS): For card data.
• Foreign Direct Investment (FDI) Policy: For marketplace model compliance (not information security directly, but often linked to data governance).
• Logistics partner contracts: Data sharing and security obligations.

Implementation tip: Map every seller and logistics partner contract into the register. Ensure grievance officer contact details and data retention policies are accurate and published.

Manufacturing and Operational Technology (OT)

Manufacturing organizations with OT/ICS environments must add:

• National Critical Information Infrastructure Protection Centre (NCIIPC) guidelines if designated as critical infrastructure.
• Factories Act and state-specific industrial safety laws.
• Export control regulations for dual-use technology.
• Vendor contracts for industrial control systems and IoT devices.

Implementation tip: Create a separate OT compliance section in the register. Map OT-specific incident reporting requirements and ensure IT and OT security teams share regulatory intelligence.

Tools, Technologies, and Solutions

GRC and Compliance Management Platforms

Regulatory Intelligence Tools

Contract Lifecycle Management (CLM)

Document and Evidence Management

Spreadsheet Option

For small organizations, a well-structured Excel or Google Sheet register is acceptable if it includes:

• Unique IDs
• Categories and jurisdictions
• Requirement text
• Owners and review dates
• Status and evidence links
• Version control (filename with date)

Policy and Procedure Templates

Legal, Regulatory and Contractual Compliance Policy

LEGAL, REGULATORY AND CONTRACTUAL COMPLIANCE POLICY
[Organization Name]
Version: 1.0
Approved by: [CEO / Managing Director]
Date: [Date]
Review Date: [Date + 12 months]
Classification: Internal

---

1. PURPOSE AND SCOPE

1.1 Purpose
This policy establishes the framework for identifying, documenting, maintaining, and
integrating all legal, statutory, regulatory, and contractual requirements relevant to
information security into the ISMS.

1.2 Scope
This policy applies to all employees, contractors, vendors, suppliers, and third parties
who access, process, store, or transmit [Organization Name] information assets. It covers
all jurisdictions where the organization operates and all contracts with security or data
protection obligations.

2. POLICY STATEMENT

[Organization Name] shall:
2.1 Maintain a Legal and Compliance Register of all applicable legal, statutory,
     regulatory, and contractual requirements.
2.2 Assign ownership for each requirement.
2.3 Review the register at planned intervals (at least annually) and when significant
     changes occur.
2.4 Translate requirements into policies, procedures, and technical controls.
2.5 Demonstrate compliance through maintained evidence.
2.6 Report compliance status to management review.
2.7 Ensure all personnel are aware of their compliance responsibilities.

3. ROLES AND RESPONSIBILITIES

3.1 Top Management
    • Approve this policy and the compliance strategy.
    • Provide resources for compliance management.
    • Review compliance status at management review.

3.2 Compliance Officer / CISO
    • Own the Legal and Compliance Register.
    • Coordinate reviews and updates.
    • Report metrics and incidents.

3.3 General Counsel / Legal Counsel
    • Interpret laws, regulations, and contracts.
    • Advise on new and changed requirements.
    • Review contractual security clauses.

3.4 Data Protection Officer (if applicable)
    • Own privacy-related obligations.
    • Manage Data Principal rights and breach notifications.

3.5 Department Heads
    • Implement compliance controls within their domain.
    • Provide evidence of compliance.

3.6 All Employees
    • Comply with policies and procedures derived from legal/contractual requirements.
    • Report suspected non-compliance.

4. LEGAL AND COMPLIANCE REGISTER

4.1 The register shall include, as a minimum:
    • Unique identifier
    • Category (law, regulation, contract, standard, policy commitment)
    • Name and jurisdiction
    • Applicability
    • Requirement text or summary
    • Owner
    • Control / procedure reference
    • Evidence location
    • Status
    • Risk level
    • Review frequency and dates

4.2 The register shall be stored centrally with controlled access.
4.3 Changes shall be version-controlled.

5. IDENTIFICATION OF REQUIREMENTS

5.1 Internal Sources
    • Customer contracts and MSAs
    • Vendor and supplier agreements
    • Employment contracts
    • Privacy notices
    • Security questionnaires and RFP responses
    • Audit reports and incident history

5.2 External Sources
    • Central and state legislation
    • Regulator directions, circulars, and notifications
    • Industry standards
    • International laws applicable to operations

6. REVIEW AND MAINTENANCE

6.1 The register shall be reviewed at least annually.
6.2 Triggers for ad-hoc review include:
    • New or amended legislation
    • New regulator guidance
    • New or amended contracts
    • Mergers, acquisitions, or divestitures
    • New products, services, or geographies
    • Significant incidents or audit findings
    • Changes in business model or technology

7. INTEGRATION WITH ISMS

7.1 Requirements shall be mapped to policies, procedures, and controls.
7.2 Compliance risks shall be included in the risk register.
7.3 Training shall include awareness of relevant legal and contractual obligations.
7.4 Internal audit shall verify implementation.

8. NON-COMPLIANCE AND ESCALATION

8.1 Non-compliance shall be recorded and escalated to the Compliance Committee.
8.2 Remediation plans shall be defined with timelines and owners.
8.3 Repeated or material non-compliance shall be escalated to top management.

9. POLICY REVIEW

This policy shall be reviewed annually and when significant changes occur.

APPROVED BY:
[CEO Name]                          Date: [Date]
[CISO Name]                         Date: [Date]
[General Counsel Name]              Date: [Date]

Procedure for Maintaining the Legal and Compliance Register

PROCEDURE: MAINTENANCE OF THE LEGAL AND COMPLIANCE REGISTER
Version: 1.0
Owner: Compliance Officer

1. PURPOSE
To define the steps for identifying, documenting, reviewing, and updating the Legal and
Compliance Register.

2. SCOPE
All legal, statutory, regulatory, and contractual requirements relevant to information
security.

3. PROCEDURE

3.1 Identification
    a. Legal Counsel reviews internal contracts and external legal/regulatory sources.
    b. CISO reviews customer security requirements and industry standards.
    c. DPO reviews privacy laws and data protection obligations.
    d. Procurement reviews supplier security clauses.
    e. HR reviews employment law obligations.

3.2 Documentation
    a. Compliance Officer creates or updates register entries using the standard template.
    b. Each entry is assigned a unique ID, owner, status, risk level, and review date.
    c. Evidence locations are linked.

3.3 Review
    a. Annual review: Compliance Officer initiates full review 60 days before the anniversary.
    b. Ad-hoc review: Triggered by change events; owner updates within defined timelines.
    c. Reviewers verify applicability, status, and evidence.

3.4 Approval
    a. Updated register is approved by Compliance Officer and Legal Counsel.
    b. Significant changes are reported to Compliance Committee.

3.5 Communication
    a. Relevant personnel are informed of new or changed obligations.
    b. Training is updated if needed.

3.6 Evidence Maintenance
    a. Owners upload evidence to the designated repository.
    b. Evidence is reviewed for completeness during audits.

4. RECORDS
    • Legal and Compliance Register (master and archived versions)
    • Review meeting minutes
    • Evidence files
    • Training records

5. REVIEW
This procedure is reviewed annually.

Contract Security Review Checklist

CONTRACT SECURITY REVIEW CHECKLIST
Contract Name: __________________________
Counterparty: __________________________
Review Date: __________________________
Reviewer: __________________________

□ Information security standards required (ISO 27001, SOC 2, PCI DSS, etc.)
□ Data protection and privacy obligations defined
□ Data residency and localization requirements
□ Subprocessor and third-party restrictions
□ Audit rights and frequency
□ Security assessment / questionnaire requirements
□ Incident reporting timelines
□ Breach notification timelines
□ Confidentiality and NDA terms
□ IP ownership and license terms
□ Data return / deletion on termination
□ Liability and indemnification clauses
□ Insurance requirements
□ Business continuity / DR obligations
□ Penalties / service credits for non-compliance
□ Change notification requirements
□ Governing law and dispute resolution
□ Records retention requirements
□ Cross-border data transfer mechanism
□ Data subject rights obligations

Owner Assigned: __________________________
Register Updated: __________________________

Risk Assessment and Treatment

Risk Scenarios Specific to A.5.31

Risk Treatment Plan Template

Audit and Compliance Checklist

Internal Audit Checklist for A.5.31

Metrics and KPIs

Common Pitfalls / Audit Failures & How to Avoid Them

Illustrative Scenarios

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

Illustrative Scenario 1: Indian Fintech Avoids RBI Enforcement Action Through Proactive Compliance Register

Organization: A Bengaluru-based payments fintech with 400 employees processing UPI and card transactions.

Challenge: In early 2024, the fintech faced a ransomware incident that encrypted several non-production systems. The CISO discovered that the incident response team was unsure whether the event was reportable to RBI within 2 hours, to CERT-In within 6 hours, or only to customers. Customer contracts had varying breach notification timelines ranging from 4 hours to 48 hours. The organization had no central register of these overlapping obligations. As a result, the incident was reported late to one regulator and two enterprise customers, exposing the company to enforcement risk and contract penalties.

Solution: The fintech engaged Singahi to implement A.5.31:

1. Built a Legal and Compliance Register covering IT Act 2000, DPDP Act 2023, CERT-In Directions 2022, RBI Cyber Security Framework, PCI DSS v4.0, and 35 active customer MSAs.
2. Mapped each obligation to an owner, policy, procedure, and evidence location.
3. Created an incident reporting decision tree with clear thresholds and timelines for RBI, CERT-In, NPCI, and customers.
4. Automated alerts in the SIEM and GRC tool for reportable incidents.
5. Trained the SOC, CISO office, and customer success team on the new process.
6. Added a contract review gate in Salesforce so no customer contract with security clauses could be signed without CISO and Legal approval.

Results:

• Incident reporting compliance improved from 60% to 100% within two quarters.
• Zero late regulator reports in the following 12 months.
• Customer contract penalties avoided: estimated in liquidated damages.
• RBI cyber audit in 2025 found no major observations related to compliance obligations.
• ISO 27001 surveillance audit passed with zero non-conformities on A.5.31.

Illustrative Scenario 2: Indian SaaS Company Loses Enterprise Customer Due to Contractual Compliance Gap

Organization: A Pune-based HR-tech SaaS provider serving 800+ customers, including several multinational corporations.

Challenge: The SaaS provider had ISO 27001 certification and assumed it was fully compliant with customer security requirements. During a routine customer audit, a Fortune 500 customer discovered that the provider had not implemented several contractual obligations embedded in the MSA signed three years earlier:

• Annual third-party penetration testing by a CERT-In empanelled auditor.
• Encryption of backups using customer-managed keys.
• Restriction on subprocessors without prior written approval.
• 24-hour breach notification for any unauthorized access.

The provider's register contained only laws (IT Act, GDPR) but no customer-specific contractual obligations. The customer terminated the contract, citing material breach, and demanded data migration within 30 days.

Solution: After the loss, the provider rebuilt its A.5.31 program:

1. Extracted security obligations from all 800+ customer contracts using a CLM tool and manual review for top 50 customers.
2. Created a Customer Compliance Register as a subset of the Legal and Compliance Register.
3. Assigned customer obligation owners to account managers, with technical owners in engineering and security.
4. Built a pre-signing contract checklist requiring CISO review of all security clauses.
5. Implemented quarterly compliance attestations for high-risk customers.
6. Integrated the register with Jira for action tracking and Confluence for evidence storage.

Results:

• Customer churn related to security compliance dropped to zero in the next 12 months.
• The company won back the lost enterprise customer after 18 months by demonstrating the new program.
• Annual contract value at risk reduced by .
• ISO 27001 recertification audit in 2025 highlighted A.5.31 as a strength.

Illustrative Scenario 3: Indian Healthtech Start-Up Prepares for DPDP Act Using A.5.31

Organization: A 120-employee healthtech start-up collecting patient vitals, lab reports, and insurance information.

Challenge: With the DPDP Act 2023 coming into force, the start-up needed to demonstrate reasonable security safeguards, consent management, Data Principal rights, and breach notification readiness. The company had scattered awareness of SPDI Rules 2011 but no structured compliance register. Investors and hospital customers were demanding DPDP readiness proof.

Solution: The start-up implemented A.5.31 as the foundation for DPDP compliance:

1. Identified all applicable laws: DPDP Act 2023, IT Act 2000, SPDI Rules 2011, ICMR data guidelines, IRDAI guidelines (for insurance integrations), and customer hospital contracts.
2. Documented obligations in the register with owners from legal, product, engineering, and customer success.
3. Mapped DPDP obligations to controls: consent notice (product), security safeguards (CISO), Data Principal rights (DPO), breach notification (SOC + DPO).
4. Conducted a Data Protection Impact Assessment (DPIA) for high-risk processing.
5. Updated privacy notice, consent flows, and data retention schedules based on the register.
6. Trained all staff on DPDP and contractual hospital obligations.

Results:

• Closed a Series B funding round with compliance as a key diligence strength.
• Passed customer security audits by two major hospital chains.
• Zero findings on legal and contractual compliance in ISO 27001 Stage 2 audit.
• Positioned as a DPDP-ready vendor in enterprise sales.

Multi-Framework Mapping

Implementation Roadmap

Week-by-Week Roadmap

Phase 1: Foundation (Weeks 1–2)

Phase 2: Build the Register (Weeks 3–5)

Phase 3: Implement and Integrate (Weeks 6–8)

Phase 4: Operate and Improve (Ongoing)

FAQ

Q1: Does A.5.31 require us to list every law in India? No. It requires you to identify every legal, statutory, regulatory, and contractual requirement relevant to information security. Focus on laws and contracts that affect your business, industry, data types, and geographies.

Q2: Is a spreadsheet enough for the Legal and Compliance Register? For small organizations, a well-maintained spreadsheet is acceptable. For medium and large organizations, a GRC tool or dedicated compliance platform is recommended for scalability, evidence linking, and audit readiness.

Q3: How often must the register be reviewed? At planned intervals, typically annually, and whenever significant changes occur (new laws, new contracts, mergers, incidents, etc.).

Q4: Who should own the register? Typically the CISO, Compliance Officer, or DPO. Legal Counsel supports interpretation. Each requirement should have a named owner responsible for implementation and evidence.

Q5: Do customer contracts need to be in the register? Yes. Contractual security and data protection obligations are explicitly in scope of A.5.31. Extract key clauses and assign owners.

Q6: How does A.5.31 relate to DPDP Act compliance? A.5.31 is the mechanism by which DPDP Act obligations are identified, documented, and integrated into the ISMS. DPDP-specific controls are then implemented under A.5.34 and other controls.

Q7: What happens if we miss a new regulation? That is a compliance risk. Mitigate through regulatory intelligence, legal retainers, industry associations, and trigger-based register reviews.

Q8: Is A.5.31 only about Indian laws? No. If your organization handles EU, US, Singapore, or other jurisdictions' data or has customers there, those laws must also be in the register.

Q9: Can we use our legal team alone for A.5.31? Legal interprets laws and contracts, but A.5.31 requires integration into the ISMS. The CISO, DPO, risk manager, and operational owners must be involved.

Q10: What evidence do auditors expect? The register itself, review records, policies/procedures referencing obligations, evidence of compliance (logs, reports, certificates), training records, and management review minutes.

References and Further Reading

Standards

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements.
• ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls.
• ISO/IEC 27701:2019, Privacy information management systems.
• ISO/IEC 27017:2015, Code of practice for information security controls based on ISO/IEC 27002 for cloud services.
• ISO/IEC 27018:2019, Protection of personally identifiable information (PII) in public clouds.

Indian Laws and Regulations

• Digital Personal Data Protection Act, 2023.
• Information Technology Act, 2000.
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011.
• Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021.
• CERT-In Directions, 2022.
• Reserve Bank of India, Master Direction on Information Technology Framework for the NBFC Sector.
• Reserve Bank of India, Cyber Security Framework in Banks.
• SEBI Circular CIR/MRD/DP/13/2015 on Cyber Security and Cyber Resilience.
• SEBI Master Circular SEBI/HO/MIRSD/MIRSD-PoD-1/P/CIR/2023/70.
• IRDAI (Information and Cyber Security) Guidelines, 2017.
• IRDAI Master Circular on Information and Cyber Security for Insurers.
• Consumer Protection Act, 2019.
• Consumer Protection (E-Commerce) Rules, 2020.
• Companies Act, 2013.
• Copyright Act, 1957.
• Patents Act, 1970.
• Trade Marks Act, 1999.
• Prevention of Money Laundering Act, 2002.

International Laws

• General Data Protection Regulation (EU) 2016/679.
• UK Data Protection Act 2018.
• California Consumer Privacy Act (CCPA) / California Privacy Rights Act (CPRA).
• Singapore Personal Data Protection Act 2012.
• UAE Personal Data Protection Law.

Guidance and Reports

• NASSCOM-DSCI Data Security Council of India, Best Practices.
• RBI Cyber Security Framework in Banks.
• IBM impact of a Data Breach Report 2024.
• ENISA Threat Landscape Reports.