Contract Management

CLM security evaluation is not completed by confirming that a vendor holds SOC 2 and ISO 27001 certifications. Most enterprise CLM vendors hold one or both. The certifications are a starting point, not a conclusion. What they tell you depends on what type of certification it is, what scope it covers, how old it is, whether it has any noted exceptions, and whether the scope actually covers the systems and data handling practices that are relevant to your use case. Enterprise procurement teams that complete CLM security evaluation at the badge level, noting “SOC 2 yes, ISO 27001 yes”, and moving on, are accepting a vendor’s self-selected evidence of their security posture. The evaluation does not surface the questions that matter: whether the certification covers the data that will actually be processed, whether the controls operated effectively over time, and whether the vendor’s security practices meet the specific requirements of the Indian regulatory environment. This article explains what SOC 2 and ISO 27001 certifications mean in the context of CLM evaluation, how to interpret them correctly, and what the India-specific security requirements are that these global certifications do not automatically address. What SOC 2 Is and What It Actually Tells You SOC 2 is a framework developed by the American Institute of Certified Public Accountants that evaluates how a service organisation manages data against five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Type I versus Type II This distinction is the first and most important thing to establish in a CLM security evaluation. SOC 2 Type I is a point-in-time assessment. An auditor reviews the vendor’s security controls and confirms that they were designed and in place at a specific date. Type I tells you that controls existed on audit day. It does not tell you whether those controls worked over time. SOC 2 Type II covers an extended audit period, typically six to twelve months. The auditor tests whether the controls actually operated effectively throughout that period. Type II is the meaningful certification for enterprise procurement purposes. A Type II report with a twelve-month audit period tells you that controls were in place and functional over an extended period of time, not just on a single day. Always ask for SOC 2 Type II. If a vendor presents a Type I report, ask why they do not have Type II and what their timeline is for obtaining it. What the five criteria cover Security is the only mandatory criterion in a SOC 2 report. It covers protection against unauthorised access, both physical and logical. The other four criteria are included based on the vendor’s product scope and customer requirements. For a CLM platform, the criteria most relevant to your evaluation are: Security: Access controls, encryption, vulnerability management, and monitoring. This is mandatory and should be in every SOC 2 report. Confidentiality: Protection of information designated as confidential. For a CLM platform that stores commercially sensitive contracts, pricing terms, and negotiated provisions, confidentiality is directly relevant. Ask whether the vendor’s SOC 2 scope includes the Confidentiality criterion. Availability: System uptime and performance against defined commitments. If your enterprise depends on the CLM for time-sensitive contract workflows, availability is relevant. Privacy: Handling of personal information in accordance with the vendor’s stated privacy practices. If contracts stored in the CLM contain personal data of individuals, the Privacy criterion is relevant. Reading a SOC 2 report for exceptions A SOC 2 Type II report includes the auditor’s findings on each tested control. When controls did not operate as designed during the audit period, the report notes exceptions. These exceptions are the most important part of the report for procurement evaluation. An exception in a SOC 2 report means that a control that was supposed to work did not work at some point during the audit period. The vendor’s response to the exception, and whether it has been remediated, should be requested and reviewed. A vendor with one or two exceptions in an otherwise clean report is not necessarily a red flag if the remediation was prompt and documented. A vendor with multiple exceptions across key security controls is providing evidence of systemic control weakness that the certification badge does not surface. Ask vendors specifically: are there any noted exceptions in your most recent SOC 2 Type II report? How have they been remediated? Audit period currency A SOC 2 Type II report from two years ago is not current evidence of security posture. Security environments change: new vulnerabilities emerge, new system components are deployed, staff changes occur. An evaluation based on a two-year-old report is an evaluation of security posture that may no longer reflect the current state. Ask when the most recent SOC 2 Type II audit period ended. Anything beyond twelve months ago should be followed up with a question about when the next audit is expected. What ISO 27001 Is and What It Actually Tells You ISO 27001 is an international standard for Information Security Management Systems published by the International Organization for Standardization. Where SOC 2 assesses specific security controls in a product or service, ISO 27001 certifies that the vendor’s organisation operates a systematic, risk-based approach to information security management. The current standard: ISO/IEC 27001:2022 The current version of the standard is ISO/IEC 27001:2022, published in October 2022. The previous version, ISO/IEC 27001:2013, was withdrawn, with the transition deadline passing on October 31, 2025. Vendors who hold a 2013 certification that has not been transitioned to the 2022 standard are holding a lapsed certification. Confirm that the vendor holds the 2022 version. The 2022 update restructured the Annex A controls from 114 controls across 14 domains to 93 controls across 4 themes: Organisational (37 controls), People (8 controls), Physical (14 controls), and Technological (34 controls). New controls were added covering cloud security, data masking, information deletion, and monitoring activities, among others. Why ISO 27001 matters for Indian enterprises with international operations ISO 27001 certification is particularly relevant for Indian enterprises that work with international

Section 65B of the Indian Evidence Act, 1872, governs how electronic records, including digital contracts, are admitted as evidence in Indian courts. For enterprise legal teams managing large volumes of electronically executed agreements, understanding Section 65B is not an academic exercise. It is the difference between a digital contract that is enforceable in a dispute and one that cannot be admitted in evidence because the certification requirements were not met. With over 85% of businesses now using electronic contracts, the volume of digitally executed agreements that need to meet Section 65B requirements has grown substantially. A digital contract that is admissible as evidence in a Section 65B compliance framework is a legally effective document. One that is not certified correctly is vulnerable to challenge at the point when its enforceability matters most. This article covers what Section 65B requires, how the Bharatiya Sakshya Adhiniyam 2023 has updated the framework, what the key Supreme Court interpretations establish, and what enterprise legal teams need to do to ensure their digital contracts meet the admissibility standard. What Section 65B Is Section 65B was introduced into the Indian Evidence Act by the Information Technology Act, 2000. It provides the mechanism by which electronic records, which by their nature do not exist as physical documents, can be admitted as documentary evidence in Indian courts. The section provides that any information contained in an electronic record, printed on paper, stored, recorded, or copied in optical or magnetic media, produced by a computer, shall be deemed to be a document and admissible as evidence without further proof or production of the original, if the conditions specified in the section are satisfied. The practical effect is that electronic records, including digitally executed contracts, can be produced and relied upon as evidence in court proceedings without having to produce the original device or system that created them. This is the mechanism that makes digital contracts legally useful: not just valid as agreements (which Section 10A of the IT Act addresses) but admissible as evidence when their terms need to be proved in a dispute. The Bharatiya Sakshya Adhiniyam, 2023 A critical update for legal teams: the Indian Evidence Act, 1872 was replaced by the Bharatiya Sakshya Adhiniyam, 2023 (BSA 2023), which came into force on July 1, 2024. The BSA 2023 is the current governing legislation for evidence in Indian courts. Section 65B of the Indian Evidence Act is substantially replicated in Section 63 of the BSA 2023. The admissibility framework for electronic records, the conditions for admissibility, and the certificate requirement are all carried forward. Legal teams that have developed compliance frameworks around Section 65B should review those frameworks against Section 63 of the BSA 2023 to ensure they remain current. References to “Section 65B” continue to be used in legal practice and in the existing body of case law, and this article addresses both the established Section 65B framework and its continuation in the BSA 2023. The Four Conditions for Admissibility Section 65B (and its successor Section 63 of the BSA 2023) specifies four conditions that must be satisfied for an electronic record to be admissible as a document in court. Condition 1: The computer output must have been produced by the computer in regular use. The electronic record must have been produced by a computer that was, at the time of production, in regular use for storing or processing information for the activities of the organisation. This condition ensures that the electronic record comes from a reliable, functioning system that was in active use, not from a system specifically set up to produce evidence after the fact. Condition 2: The computer must have been in regular use throughout the relevant period. The computer must have been in regular use during the period over which the electronic record was created or stored. If the computer was used only intermittently, or if there was a period when it was not in use during the relevant time, the admissibility of records from that period may be affected. Condition 3: The computer was operating properly. The computer must have been operating properly throughout the relevant period, or any malfunctions that occurred must not have affected the electronic record or the accuracy of its contents. A record produced by a malfunctioning system, or where system errors may have affected the record’s contents, does not satisfy this condition. Condition 4: The information in the electronic record was fed into the computer in the ordinary course of activities. The information recorded in the electronic record must have been fed into the computer (or derived from information fed into the computer) in the ordinary course of the activities to which the record relates. This condition prevents the production of records that were created specifically for litigation rather than in the normal course of business. A contract that was executed and stored in the ordinary course of the organisation’s commercial activities satisfies this condition. A record created or modified for the purpose of a specific proceeding does not. The Certificate Requirement In addition to the four conditions, Section 65B(4) requires that the electronic record be accompanied by a certificate identifying the record, describing the manner in which it was produced, and giving particulars of the device involved in its production. The certificate must be signed by a person occupying a responsible official position in relation to the operation of the relevant device or the management of the relevant activities. What the certificate must contain The courts have clarified what the Section 65B certificate needs to address. The certificate should include: The certificate is to be given based on the best of the person’s knowledge and belief. Courts have also clarified that if the person responsible for issuing the certificate refuses to do so, a court can direct or summon its production. Primary versus secondary electronic evidence A distinction that enterprise legal teams need to understand is the difference between primary and secondary electronic evidence in the context of Section 65B. When an electronic record

Contract amendments are a routine part of enterprise contract management. Business conditions change. Commercial terms need adjustment. Scope modifications arise from project developments. Regulatory requirements create new obligations that need to be incorporated into existing agreements. For a large enterprise managing hundreds of active contracts, amendments are a continuous workflow, not an occasional event. The challenge is not executing amendments. The challenge is managing them without creating gaps in the contract record that undermine the organisation’s understanding of what is currently agreed, and without losing the audit history that shows what was changed, when, and why. When contract amendments are managed informally, through email exchanges, scanned attachments, and handwritten additions to printed documents, the result is a fragmented record. The original contract says one thing. An email thread from six months later says something slightly different. A second addendum adds a new clause without referencing the first. Nobody is entirely sure which version is controlling. When a dispute arises, or an audit requires production of the contract record, reconstructing what was actually agreed across all amendments requires significant effort and produces incomplete results. This article covers what contract amendments are, the main types, the risks of inadequate amendment management, and the practices that enterprise legal teams use to manage amendments systematically while maintaining audit-ready records. What Contract Amendments Are A contract amendment is any change to the terms of an executed agreement, made after the original contract has come into force. Amendments can range from minor corrections to fundamental changes in the commercial relationship. The terms used for different types of post-execution modifications vary, but the most common are: Amendment or addendum: A formal modification to specific terms of the original agreement. An amendment changes what the contract says. An addendum may add new terms without changing existing ones. In practice, the two terms are often used interchangeably. Variation: A change to the scope, deliverables, or timeline of an agreement, commonly used in project and services contracts. Variation procedures are typically defined in the contract itself, specifying how variations are initiated, assessed, priced, and approved. Novation: A formal substitution of one party with another, or of one obligation with a different obligation, with the agreement of all parties. Novation is more significant than an amendment because it extinguishes the original obligation and replaces it with a new one. Side letter: An agreement between parties that operates alongside the main contract and modifies or supplements its terms. Side letters are sometimes used to document commercial arrangements that the parties do not want to incorporate formally into the main agreement. They carry the same legal weight as a formal amendment but are more prone to being lost or overlooked in contract records. Waiver: A party’s agreement to forgo a contractual right on a specific occasion. A waiver is not a permanent amendment to the contract, but if waivers are repeated or documented in writing without reservation of rights, they can affect the enforceability of the original term. Why Contract Amendments Create Audit Trail Risk Every amendment to an executed contract creates a version management challenge. The original contract, the first amendment, the second amendment, and any side letters or waivers collectively define what the parties have agreed. If any of these documents is missing from the record, or if the relationship between them is unclear, the contract record is incomplete. This creates three specific risks. Enforceability risk. A party relying on a contractual right needs to be able to produce the full contract record, including all amendments, in a form that demonstrates the current state of the agreement. If the amendment that created the right in question is missing, or if its relationship to the original contract is unclear, the enforceability of the right is weakened. In a dispute, the other party will exploit any gap in the contract record. Audit risk. Regulatory inspections and internal audits may require production of the complete contract record for specific agreements. For regulated sectors in India, this is not a hypothetical. RBI inspections, IRDAI reviews, and SEBI audits all involve examination of contractual arrangements. A fragmented amendment record, where some changes are in formal amendment documents and others are in email threads or informal side letters, does not meet the documentation standard that regulators expect. Operational risk. When the current state of a contract is unclear because amendments are scattered across multiple documents in different formats, the team managing the relationship operates with an incomplete picture. Obligations from the original contract that were modified by a later amendment may be tracked and performed as originally agreed rather than as amended. Pricing that was adjusted in an amendment may not be reflected in actual invoicing. Rights that were waived temporarily may be treated as permanently waived. These operational failures create disputes and financial leakage. The Amendment Process: What It Should Cover A structured amendment process covers five elements. Initiation and documentation of the change request Every amendment starts with a change request: a party identifying that a modification to the existing agreement is needed. For project and services contracts with formal variation procedures, this typically follows a defined process in the contract. For other contract types, the change request may originate from a business team, a counterparty communication, or a regulatory requirement. The change request should be documented from the outset: who is requesting the change, what change is being requested, the business or legal justification, and the impact assessment on the existing agreement. This documentation becomes part of the amendment’s audit history. Legal review of the proposed change Every amendment should go through a legal review that assesses: whether the proposed change is consistent with the organisation’s standard positions, whether it creates new risk that requires escalation, and whether the change is properly captured in contract language that is precise and unambiguous. For amendments involving regulatory obligations, the review should assess whether the change satisfies the relevant regulatory requirements or creates compliance risk. An amendment to a data processing agreement needs to be assessed

Third-party risk management is the process of identifying, assessing, and mitigating the risks that arise from an organisation’s relationships with external parties: vendors, suppliers, service providers, technology partners, outsourced functions, and any other third party that has access to the organisation’s data, systems, operations, or customers. For enterprise legal and compliance teams, third-party risk is fundamentally a contractual risk. The relationship between an organisation and its third parties is governed by contracts. The obligations a third party must meet, the standards they must maintain, the rights the organisation has to audit and enforce, and the remedies available when a third party fails are all defined in contract terms. When contract controls are structured and enforced, third-party risk is managed. When they are not, third-party relationships create exposure that may not be visible until a breach, a regulatory inspection, or a business failure surfaces it. This article covers what third-party risk means in the enterprise context, what structured contract controls look like, and how Indian enterprises should approach third-party risk management given the specific regulatory requirements of the Indian environment. What Third-Party Risk Covers Third-party risk encompasses several distinct categories of exposure, each of which needs to be addressed through different contract controls. Operational risk arises when a third party’s failure to perform creates disruption to the organisation’s own operations. A logistics provider who fails to deliver on time. A technology vendor whose system goes down during a critical business period. A manufacturing supplier who cannot meet quality standards. Operational third-party risk is managed through contract terms that define performance standards, SLA commitments, business continuity requirements, and exit rights. Financial risk arises from third-party relationships that involve financial obligations: payment commitments, credit exposure, guarantee arrangements, and minimum purchase commitments. For Indian enterprises with complex group structures, financial third-party risk includes exposure from subsidiary relationships, joint venture obligations, and inter-company guarantee arrangements. Compliance and regulatory risk arises when a third party’s non-compliance creates regulatory exposure for the organisation. A Lending Service Provider that does not comply with RBI requirements creates compliance risk for the Regulated Entity that engaged them. A data processor that does not meet DPDPA obligations creates risk for the data fiduciary. A distribution channel that engages in mis-selling creates regulatory and reputational risk for the insurer or bank whose products they distribute. Data and cybersecurity risk arises when third parties have access to sensitive data, systems, or infrastructure, and their security practices are inadequate. Under India’s DPDPA, data fiduciaries are responsible for the data processing practices of their data processors. A data breach at a third-party processor is a risk event for the organisation that engaged them, not just for the processor. Reputational risk arises when third-party conduct reflects on the organisation’s brand or standing. Labour practices, environmental conduct, governance failures, and regulatory enforcement actions against third parties can create reputational exposure for the organisations they work with. What Structured Contract Controls Look Like Structured contract controls are the specific provisions in third-party agreements that give the organisation visibility into, and governance over, the risks described above. They cover six main areas. Due diligence requirements Before a third-party relationship is established, due diligence assesses the third party’s financial stability, regulatory compliance standing, data security practices, reputation, and operational capability. Structured contract controls formalise this by requiring the third party to provide representations and warranties about their status at the point of contracting, and to maintain specific standards throughout the relationship. For regulated sectors in India, due diligence requirements are mandatory rather than discretionary. The RBI’s Digital Lending Directions require Regulated Entities to assess LSPs for technical capability, data handling practices, regulatory compliance history, and experience before engagement. IRDAI’s Fraud Monitoring Framework Guidelines require insurers to conduct due diligence on distribution channels before engagement and on an ongoing basis. These regulatory requirements need to be reflected in the contract terms and in the pre-contract due diligence process. Performance standards and SLA obligations Third-party contracts need to define what performance looks like, how it is measured, and what happens when it is not met. Vague performance descriptions produce interpretation disputes. Precise SLA definitions with objective measurement criteria produce enforceable standards. For each key service or obligation, the contract should specify: the performance metric, the measurement methodology, the reporting frequency and format, the remedy for non-performance (service credits, liquidated damages, or termination rights), and the process for raising and resolving performance disputes. For Indian enterprises, performance standards for technology vendors need to address uptime commitments that account for India-specific infrastructure considerations, delivery standards for logistics providers that reflect Indian regulatory and customs requirements, and data localisation commitments for technology service providers subject to DPDPA obligations. Audit rights and inspection provisions Audit rights give the organisation the ability to verify that the third party is meeting its contractual and regulatory obligations. A contract without audit rights relies entirely on the third party’s self-reporting. A contract with audit rights gives the organisation an independent basis for assessment. Audit rights provisions should specify: who has the right to conduct audits (the organisation directly, or third-party auditors on their behalf), what the scope of the audit covers, how much notice is required, how audit findings are reported and remediated, and what happens if the third party refuses or obstructs an audit. For regulated sectors, audit rights are often mandatory. RBI’s Digital Lending Directions require Regulated Entities to have contractual audit rights over LSPs’ activities. IRDAI’s framework requires insurers to have audit rights over their distribution channels. The contract needs to reflect these regulatory requirements, not just the organisation’s own governance preferences. Data protection obligations For contracts that involve any processing of personal data of Indian citizens, DPDPA compliance provisions are a mandatory element of the contract terms. The data processing agreement between a data fiduciary and its data processor needs to address: the scope and purpose of processing, data retention and deletion requirements, breach notification obligations and timelines, data localisation requirements, restrictions on sub-processing, and the data fiduciary’s right to audit the data processor’s practices.

Clause standardisation is the process of defining approved language for the key provisions in an organisation’s contracts, establishing fallback positions for negotiation, and building systems to ensure that deviations from those standards are identified, escalated, and documented. For enterprise legal teams managing high volumes of contracts across multiple business units, clause standardisation is the foundation on which contract governance is built.

Contract risk scoring is the systematic process of assigning a quantified risk level to a contract or contract clause based on predefined criteria. For enterprise compliance teams managing hundreds or thousands of active agreements, contract risk scoring turns the subjective judgment of “this contract looks risky” into a structured, consistent, and scalable process that can be applied across the full portfolio.

Contract intelligence is the process of turning contracts from static legal documents into structured, searchable, and actionable business data. Using artificial intelligence, natural language processing, and machine learning, contract intelligence platforms read contracts, extract key terms and obligations, identify risks, and make the information accessible to legal, finance, and procurement teams in a form they can actually use.

E-signature adoption in BFSI, healthcare and government in India is no longer a question of whether electronic signing is legally valid. The Information Technology Act, 2000 settled that over two decades ago. The question today is how organisations in each of these sectors are implementing e-signatures in a way that is consistent, secure, and audit-ready at the volumes they need to operate at.

A contract lifecycle management platform holds some of the most sensitive commercial data an organisation produces. Executed agreements, pricing commitments, indemnification caps, liability thresholds, vendor terms, and confidential counterparty information all sit in one place. For enterprise procurement teams evaluating CLM vendors, security is not a secondary consideration to be reviewed after functionality. It is a foundational requirement that shapes the rest of the evaluation.

The Insurance Regulatory and Development Authority of India released the Insurance Fraud Monitoring Framework Guidelines on 9 October 2025. These Guidelines come into force on 1 April 2026 and replace the IRDAI Fraud Monitoring Framework circular that had governed the sector since January 2013.

When two parties enter into an agreement, something must be exchanged between them for that agreement to be legally enforceable. A promise made without anything in return is, in most cases, just a promise. It may be morally binding, but the law generally does not treat it as a contract.

Every contract that is validly formed must eventually come to an end. The obligations it creates — to pay, to deliver, to perform a service, to refrain from an act — cannot continue indefinitely. At some point, the legal relationship established by the contract is extinguished, and the parties are released from their duties under it.