1. Introduction

Configuration Management Baselines and Audit Evidence is an important topic in information technology law, cybersecurity governance, software engineering, government procurement, financial regulation, and corporate compliance.

Configuration management ensures that an organisation's systems, software, networks, databases, and security settings remain controlled, documented, and consistent with approved requirements. Audit evidence demonstrates whether those controls were actually followed and whether changes were properly authorised.

The legal importance of the subject lies in a fundamental question:

When an organisation claims that its computer systems were secure, properly configured, and compliant with applicable standards, what evidence can establish that claim in court or before a regulator?

The answer often depends on the quality of its configuration baselines, change-management records, access logs, system snapshots, audit trails, and evidence-preservation procedures.

This discussion focuses primarily on Indian law, with relevant United States and United Kingdom authorities where they help explain broader legal principles. The cases cited below concern electronic evidence, cybersecurity, records, regulatory duties, and audit accountability; not every case directly concerns configuration-management baselines.

2. Meaning and scope

A. Configuration management

Configuration management is the systematic process of identifying, documenting, controlling, monitoring, and verifying the configuration of information systems and related assets throughout their lifecycle.

Examples include:

Approved operating-system versions and security patches.

Firewall rules, encryption settings, and network access controls.

Software versions, application dependencies, and deployment settings.

Database permissions and backup configurations.

Cloud infrastructure settings and identity-access policies.

Configuration changes made during maintenance, upgrades, or incident response.

B. Configuration management baseline

A configuration baseline is an approved, documented reference state against which the actual configuration of a system can be compared.

For example, a bank might approve a baseline requiring multi-factor authentication, encrypted backups, restricted administrator privileges, and a defined patch level. A subsequent audit compares the live systems against that approved state and investigates any deviation.

A baseline is not simply a screenshot or a policy document. A reliable baseline should identify the system, the approved configuration, the authorising authority, the effective date, the version, and the process for approving subsequent changes.

C. Audit evidence

Audit evidence consists of information used to assess whether a system complied with an approved baseline and whether the relevant controls operated effectively.

Examples include:

Signed baseline documents and version histories.

Change requests and approval records.

System-generated logs and configuration exports.

Cryptographic hashes and trusted timestamps.

Vulnerability assessments and penetration-test reports.

Access-control records and administrator activity logs.

Incident reports, remediation records, and independent audit findings.

The evidentiary value of each item depends on its authenticity, completeness, reliability, relevance, and preservation.

3. Legal framework governing configuration baselines and audit evidence

A. Indian law

The legal framework depends on the industry, the nature of the system, the type of records, and the dispute involved.

The Information Technology Act addresses, among other matters, unauthorised acts involving computer resources under Sections 43 and 66 and the deliberate or knowing alteration, concealment, or destruction of specified computer source code under Section 65, where that code is legally required to be maintained. These provisions do not make every configuration deviation a criminal offence; the statutory elements must be established.

India Code+1

The Bharatiya Sakshya Adhiniyam, 2023, came into force on 1 July 2024. Sections 61–63 are particularly important when configuration reports, logs, exports, or other electronic records are relied upon in court. Section 63 sets out conditions for qualifying computer outputs and provides for a certificate accompanying the electronic record when that provision applies.

India Code+1

B. International technical standards

The following standards and guidance help organisations design defensible configuration-management systems:

NIST SP 800-128: Security-focused configuration management, baseline establishment, and controlled changes.

NIST SP 800-53: Security controls addressing baseline configurations, configuration settings, least functionality, monitoring, and audit logging.

NIST SP 800-171: Configuration-management requirements for systems handling covered information in relevant non-federal environments.

ISO/IEC 27001 and ISO/IEC 27002: Information-security management and control practices, including change management, configuration management, logging, and monitoring.

NIST SP 800-128 explains that a baseline is a formally reviewed and agreed configuration that can be changed only through controlled procedures. It also supports maintaining earlier approved versions for review and rollback.

NIST Publications+1

These standards are not automatically laws in India. They may nevertheless become legally or contractually significant when incorporated into a regulation, licence condition, procurement specification, service agreement, security policy, or applicable audit requirement.

4. Essential elements of a legally defensible baseline

A reliable baseline should establish what was approved, who approved it, what actually existed, and what changed.

1. Identification of configuration items

Each relevant server, application, database, network device, cloud resource, or software component should have a unique identifier and a documented owner.

2. Formal approval

The organisation should preserve the approved settings, applicable security requirements, approving authority, approval date, and baseline version.

3. Change control

Each material change should be linked to a change request, justification, risk assessment, authorisation, implementation record, and testing or rollback plan.

4. Version history and traceability

Earlier baselines should remain available so that investigators can reconstruct the configuration at the time of a breach, system failure, or disputed transaction.

5. Independent verification

Periodic comparisons should identify deviations between the approved baseline and the live configuration. Exceptions must be documented, authorised where appropriate, and corrected or formally accepted.

A baseline that is technically secure but lacks approval or version history may be insufficient to establish what the organisation was required to maintain at a particular time.

5. Audit evidence: legal significance and evidentiary quality

Audit evidence serves two distinct purposes:

Compliance evidence: It shows whether required procedures and controls were followed.

Forensic evidence: It helps reconstruct events and establish what occurred during a particular incident.

A useful audit record should ordinarily identify the system, event, date and time, relevant account or process, action performed, outcome, source of the record, and any subsequent transformation or export.

Evidentiary reliability checklist

Cryptographic hashes, digital signatures, write-protected storage, trusted timestamps, centralised logging, and independent monitoring can strengthen reliability. However, a hash alone does not prove that the original record was truthful, complete, or generated by an authorised source.

Similarly, an audit report is not conclusive merely because an auditor signed it. The underlying records, methodology, scope, independence, and limitations may all be relevant to its weight.

6. Detailed explanation of relevant case laws

The following judgments provide important legal principles for configuration-management disputes. The distinction between direct and analogous authority matters: the electronic-evidence cases below establish rules applicable to the use of system logs and digital records, rather than a universal judicial rule that every organisation must maintain a particular technical baseline.

Case 1: Anvar P.V. v. P.K. Basheer (2014)

Supreme Court of India · (2014) 10 SCC 473

Facts and issue: The dispute concerned the proof and admissibility of electronic records in an election-related proceeding. The Supreme Court considered the statutory requirements governing electronic evidence under the former Indian Evidence Act, 1872.

Decision and principle: The Court established that secondary electronic evidence covered by Section 65B generally had to comply with the statutory certification requirements. It rejected the proposition that ordinary documentary-evidence rules could simply bypass that special procedure.

Application to configuration baselines: Suppose a company submits exported server logs to demonstrate that firewall settings were approved and unchanged before a cyberattack. The company should establish the source of the records and satisfy the applicable requirements for proving electronic evidence. An unexplained spreadsheet of log entries may be challenged if its provenance and method of production are uncertain.

Legal significance: A technically useful audit record must also satisfy the rules governing its proof in the relevant proceeding.

Case 2: Arjun Panditrao Khotkar v. Kailash Kushanrao Gorantyal (2020)

Supreme Court of India · (2020) 7 SCC 1

Facts and issue: The case arose from an election dispute and clarified the certification requirements for electronic records under Section 65B of the former Evidence Act.

Decision and principle: The Supreme Court reaffirmed the governing approach in Anvar P.V. and clarified the operation of the certificate requirement, including the position where a party cannot independently obtain a certificate from a system under another person's control. It also recognised the distinction between producing an original electronic record and relying on a computer output.

The judgment is important because it resolved conflicting approaches in earlier decisions.

Indian Kanoon+1

Application to configuration baselines: Where a cloud provider, outsourced IT operator, or former contractor controls the system that generated audit logs, an organisation may need to obtain the necessary records and supporting certification through the appropriate process. It should not assume that inability to access the provider's infrastructure makes the ordinary evidentiary requirements irrelevant.

Legal significance: Record ownership, system control, and access to the source of electronic evidence should be addressed in contracts and incident-response procedures before litigation begins.

Case 3: Tomaso Bruno v. State of Uttar Pradesh (2015)

Supreme Court of India · (2015) 7 SCC 178

Facts and issue: The case involved a criminal investigation in which electronic and scientific evidence, including CCTV evidence, was relevant to establishing the facts.

Decision and principle: The judgment emphasised the importance of modern scientific and electronic evidence in investigations. However, its discussion of the admissibility rules must be read alongside the later clarification in Arjun Panditrao Khotkar, which treated Tomaso Bruno as not laying down the correct rule on the relevant Section 65B question.

Sci API+1

Application to configuration baselines: If an organisation suffers a data breach, investigators may need configuration snapshots, firewall logs, authentication records, deployment histories, and other electronic evidence to reconstruct the incident. Failure to collect relevant evidence can impair the ability to establish what happened.

Legal significance: Organisations should have procedures to identify and preserve potentially relevant technical evidence promptly. This case does not, by itself, impose a general statutory obligation to maintain every category of configuration log.

Case 4: State (NCT of Delhi) v. Navjot Sandhu (2005)

Supreme Court of India · (2005) 11 SCC 600

Facts and issue: The case concerned a major criminal investigation involving electronic and other evidence, including records of communications.

Decision and principle: The Court adopted a more permissive approach to proving certain electronic records under the former Evidence Act. That approach was subsequently displaced on the relevant point by Anvar P.V. and reaffirmed in Arjun Panditrao Khotkar.

Application to configuration baselines: The case is useful historically because it illustrates why organisations should not rely on outdated assumptions about the admissibility of digital records. A log that was accepted under an earlier understanding of evidentiary procedure may face different scrutiny under the governing legal framework.

Legal significance: Audit procedures should be designed around the current statute and controlling precedents, not merely past practices.

Case 5: K.S. Puttaswamy v. Union of India (2017)

Supreme Court of India · (2017) 10 SCC 1

Facts and issue: The case concerned whether privacy is protected as a fundamental right under the Constitution of India.

Decision and principle: A nine-judge Bench unanimously recognised privacy as a fundamental right, grounded in the guarantees of Part III of the Constitution, including Article 21.

Application to configuration management: Audit evidence can contain employee identifiers, authentication histories, customer information, network activity, and other personal data. An organisation should therefore consider who may access audit records, how long they are retained, and whether unnecessary personal information is collected.

Legal significance: Auditability does not justify unlimited surveillance. Security monitoring should be designed consistently with applicable privacy and data-protection requirements.

This judgment does not prescribe a particular configuration-baseline standard, but its constitutional privacy principles are relevant when designing monitoring and evidence-retention practices.

Case 6: Shreya Singhal v. Union of India (2015)

Supreme Court of India · (2015) 5 SCC 1

Facts and issue: The case challenged provisions of the Information Technology Act, including Section 66A, concerning online communications.

Decision and principle: The Court struck down Section 66A as unconstitutional because it violated freedom of speech under Article 19(1)(a) and was not saved by Article 19(2).

Application to configuration management: This case illustrates the importance of distinguishing a technical system control from its legal justification. Organisations should ensure that monitoring, content filtering, account restrictions, and other controls have a lawful basis and are implemented consistently with applicable constitutional and statutory requirements.

Legal significance: Technical enforcement mechanisms must operate within the law. This judgment does not establish a direct rule about configuration baselines or audit certificates.

Case 7: Sonu @ Amar v. State of Haryana (2017)

Supreme Court of India · (2017) 8 SCC 570

Facts and issue: The case addressed the treatment of electronic evidence and the timing of objections to its admissibility.

Decision and principle: The Court distinguished objections relating to the admissibility of evidence from objections concerning the mode or manner of proving it. The procedural context matters when determining whether an objection has been waived.

Application to configuration management: A party relying on configuration exports or system logs should raise and address evidentiary issues at the appropriate stage. Equally, a party challenging those records should identify whether the objection concerns statutory admissibility, authenticity, integrity, completeness, or the weight of the evidence.

Legal significance: Proper evidence preparation reduces avoidable disputes about how technical records are introduced and proved in court.

The case must be read together with Anvar P.V. and Arjun Panditrao Khotkar on the specific requirements for electronic evidence. The distinction between admissibility and evidentiary weight remains important.

7. How the current Indian electronic-evidence law applies

The Bharatiya Sakshya Adhiniyam, 2023 (BSA), replaced the former Indian Evidence Act, 1872, with effect from 1 July 2024. For current proceedings, the applicable statutory provisions and transitional rules must be checked.

Section 61: Recognises the legal effect of electronic and digital records, subject to the Act.

Section 62: Directs that the contents of electronic records be proved in accordance with Section 63.

Section 63: Governs qualifying computer outputs and their admissibility requirements, including the prescribed certificate where applicable.

India Code+1

The earlier judgments under Sections 65A and 65B of the Indian Evidence Act remain important when interpreting corresponding principles under the BSA, but the precise application must be checked against the current statutory text.

A configuration audit should therefore preserve not just a report but also the underlying records, information about the system that generated them, the method of extraction, and the documentation required to prove them.

8. Liability for deficient configuration management

A configuration failure does not automatically establish legal liability. Liability depends on the applicable duty, the conduct of the relevant party, causation, the loss or harm suffered, and the requirements of the particular legal claim.

The IT Act's Section 65 is particularly specific: it addresses knowing or intentional concealment, destruction, or alteration of computer source code required by law to be maintained. It should not be treated as a general offence covering every deletion of an ordinary audit log.

India Code+1

9. Illustrative legal case study: Unauthorised firewall modification

Consider a hypothetical bank whose approved baseline prohibits direct administrative access from the public internet.

An administrator changes the firewall configuration without approval. The modification creates an exposed service, attackers exploit it, and customer information is accessed.

Incident reconstruction

Approved baseline: A signed and version-controlled document records the required firewall rules.

Change history: The change-management system contains no authorised request for the disputed modification.

Technical evidence: Firewall exports, identity-provider logs, deployment records, and monitoring alerts indicate when the configuration changed.

Integrity verification: Investigators preserve the original records, document extraction procedures, and calculate hashes of preserved copies.

Expert analysis: A qualified examiner compares the approved baseline with the incident-time configuration and assesses whether the deviation enabled the attack.

Legal assessment: The organisation evaluates its regulatory duties, contractual obligations, potential liability, and any applicable reporting requirements.

Questions a court or regulator may examine

Was the baseline actually approved and in force at the relevant time?

Did the organisation have an applicable legal or contractual duty to maintain that configuration?

Who or what process made the change?

Were the logs complete, authentic, and preserved appropriately?

Did the deviation cause or materially contribute to the incident?

Were the organisation's monitoring, response, and remedial measures reasonable?

Does the evidence satisfy the applicable procedural requirements?

The evidence may support a finding of inadequate control, unauthorised activity, or breach of duty. However, an unapproved change alone does not conclusively establish who made it, whether the change caused the loss, or whether a particular statutory offence occurred.

10. Best practices for maintaining defensible audit evidence

Organisations should consider the following controls as part of a risk-based programme.

Baseline governance: Assign a responsible owner and require documented approval of material baseline changes.

Immutable or tamper-evident records: Protect logs and baseline versions against unauthorised alteration.

Separation of duties: Where practicable, separate change implementation from change approval and independent verification.

Automated drift detection: Compare live configurations with approved baselines and investigate unexplained deviations.

Time synchronisation: Use reliable time sources and document time zones and clock adjustments.

Retention and legal holds: Establish retention periods under applicable laws, regulations, contracts, and litigation-preservation requirements.

Evidence chain of custody: Document who collected, transferred, accessed, examined, and preserved each evidentiary item.

Independent audits: Record the audit scope, sample selection, testing methods, exceptions, remediation, and management responses.

Cloud-provider coordination: Specify log availability, preservation, export formats, incident notification, and evidence cooperation in service agreements.

Periodic review: Update baselines after approved system changes, significant incidents, and material changes in risk or legal requirements.

These practices align with established configuration-management guidance, including NIST SP 800-128 and the configuration-management controls in NIST SP 800-171.

NIST Publications+1

11. Conclusion

Configuration management baselines establish the approved state of a system, while audit evidence establishes whether that state was maintained and whether deviations were authorised, detected, and corrected.

The central legal principles are:

A baseline must be identifiable, approved, version-controlled, and relevant to the time in question.

Audit records must be reliable, sufficiently complete, properly preserved, and attributable to their source.

Electronic evidence must satisfy the applicable statutory requirements for admissibility and proof.

Anvar P.V. and Arjun Panditrao Khotkar are especially important for understanding the legal treatment of electronic records in India.

K.S. Puttaswamy provides a constitutional privacy framework relevant to monitoring and audit-data handling.

Liability depends on the applicable duty and the evidence of breach, causation, and other legally required elements—not merely on the existence of a configuration deviation.

The overarching rule is that an organisation should be able to demonstrate not only what configuration it approved, but also what configuration actually existed, how that conclusion was reached, and whether the supporting evidence can withstand independent scrutiny.

Legal research note: This is a general legal analysis, not a substitute for advice on a particular dispute. For litigation, verify the full judgments, the current statutory text, any applicable sector-specific regulations, and the relevant transitional provisions.