1. Why Configuration Management Exists

Without CM, you get:

• Configuration Drift - production different from approved design
• Unauthorized changes causing outages / breaches
• No audit trail - cannot prove who changed what, when
• License and compliance failures

Objectives:

1. Integrity: System at any time matches its approved documentation
2. Traceability: Every change is authorized, tested, and recorded
3. Accountability: Every Configuration Item [CI] has an owner
4. Auditability: You can reconstruct any past state for legal / forensic purposes

2. Core Components

A. Configuration Item [CI]: Anything that needs to be controlled. Hardware, software, document, server, database, source code, firewall rule, license, even a SOP document.

B. Configuration Management System [CMS] / CMDB: The single source of truth. In ITIL 4, CMDB is part of CMS. It stores:

• CI attributes, version, owner, location
• Relationships - e.g., This Web App v2.3 runs on Server SRV-04, depends on DB-02
• Baseline - Approved configuration at a point in time

C. Four Key Activities:

1. Configuration Identification: Selecting and defining CIs, numbering, naming convention, creating baselines. Example: BASELINE-1.0 for Release.

2. Configuration Control [Change Control]: No CI is changed without Change Request -> Impact Analysis -> CAB Approval -> Implementation -> Verification. This is where CM links to Change Management.

3. Configuration Status Accounting: Ledger of all changes. Reports like: How many changes to CI-X in last 90 days? Who approved? What was rollback plan?

4. Configuration Audit & Verification:

• Functional Configuration Audit [FCA] - Does CI do what spec says?
• Physical Configuration Audit [PCA] - Does installed CI match documentation?

3. Types of Configuration Management

1. Software Configuration Management [SCM]: Manages source code, builds, libraries using tools like Git, SVN, Maven, Jenkins. Manages Version Control, Branching, Build Management.

2. Infrastructure / IT Service Configuration Management: Manages servers, networks, cloud infra using IaC tools like Ansible, Puppet, Chef, Terraform.

3. Product / Document Configuration Management: Used in manufacturing and regulated industries to control design documents.[pharma][aviation]

4. Legal and Compliance Angle - Why Courts Care About CM

Poor CM is treated as negligence, breach of contract, and failure of reasonable security practice under Section 43A of IT Act, 2000 and ISO 27001 Control A.8.9.

Courts do not punish you for a bug; they punish you for not having a process to prevent, detect and rollback the bug.

5. Major Case Laws Related to Configuration Management Failure

A. INDIAN CASE LAWS

1. Securens Systems Pvt. Ltd. v. Union of India & Anr. - Delhi High Court (2018)
Facts: Government tender for CCTV system rejected because bidder failed to provide configuration management documents, version control and audit trail for software. Court upheld rejection. Principle: CM documentation is an essential part of technical compliance, not a formality.

2. M/s Gujarat Informatics Ltd. v. M/s S. T. Enterprise - Gujarat HC
Dispute over custom software where vendor delivered different version from agreed baseline without change control. Court held it as breach of contract under Section 73 of Indian Contract Act. Court observed: "Absence of baseline and change log makes it impossible to determine agreed scope."

3. C-DAC and National Informatics Centre [NIC] - CAG Audit Report Cases (2010-2015)
Multiple CAG audits held government IT projects liable for lack of CMDB and version control leading to loss of public money. While not a court judgment, these are used as precedent by CAT and HC for gross negligence in public IT contracts.

B. INTERNATIONAL CASE LAWS - Foundational for India

4. BSkyB Ltd v. Electronic Data Systems Ltd [EDS] EWHC 86 [TCC] - UK - The Biggest IT Failure Case
EDS was hired to build BSkyB's CRM system. EDS misrepresented capability, failed to maintain proper configuration baseline and resource planning. System delivered late with massive configuration errors. Court awarded £200 million damages. This case is cited globally for: Failure to do proper configuration and capacity planning = fraudulent misrepresentation and breach of contract.[2010]

5. St. Albans City and District Council v. International Computers Ltd EWCA Civ 1302
Software error due to wrong configuration - population count set to 0 caused £1.3M financial loss. Court held supplier liable because software did not conform to specification and there was no adequate configuration testing. Established supplier cannot limit liability for untested configuration.[1996]

6. Knight Capital Group Trading Glitch - SEC Investigation
$440 million loss in 45 minutes. Cause: An old flag Power Peg code was re-used when new code was deployed to 8 servers, but technician deployed to only 7 servers - classic CM failure, no baseline audit. SEC held it as failure of internal controls under Exchange Act. Now taught as case study for legal liability for lack of CM.[2012]

7. FTC v. Wyndham Worldwide Corp., 799 F.3d 236 [3rd Cir. 2015] - USA
Hackers breached Wyndham due to misconfigured servers, default passwords, no firewall configuration management. FTC sued for unfair practice. Court held: Failure to maintain reasonable configuration management is an unfair trade practice under Section 5 of FTC Act. This principle is directly imported into India's Section 43A IT Act - "reasonable security practices".

8. In re: Target Corporation Customer Data Security Breach Litigation, MDL No. 14-2522
Breach via misconfigured HVAC vendor access. Court settlement $18.5M. Court noted absence of network segmentation and configuration audit.

6. Legal Best Practices to Avoid Liability

If you are drafting a CM policy for ISO 27001 / SOC 2 / DPDP Act audit, it must have:

1. Baseline and Gold Image: Every CI must have an approved baseline.
2. Change Management SOP: No direct prod changes, 4-eyes approval.
3. Version Control & Immutable Logs: Git + SIEM - logs cannot be edited.
4. Automated Drift Detection: Tools to alert if prod!= baseline.
5. Rollback Plan: Every change must have documented rollback.
6. Access Control: Separation of Dev, Test, Prod - no developer has prod write.

Applicable Standards:

• ISO/IEC 27001:2022 Annex A 8.9 - Configuration Management
• ITIL 4 - Service Configuration Management Practice
• NIST SP 800-128 - Guide for Security-Focused Configuration Management

Do you want this in a specific format?

1. For Software Engineering exam [with SCM diagrams and tools]?
2. For ITIL / ISO 27001 audit document with policy template?
3. For Legal research - full case briefs with ratio decidendi?