Version control — SY0-701

WHAT IT IS

Version control is a practice within configuration management that records and tracks every change made to a configuration item — hardware, software, or documentation — so that each distinct state of that item can be identified, retrieved, and compared over time.

The grounding comes from two NIST definitions working together. NIST SP 800-128 defines configuration management as "a collection of activities focused on establishing and maintaining the integrity of information technology products and systems, through control of processes for initializing, changing, and monitoring the configurations of those products and systems throughout the system development life cycle." Version control is one of those control processes. A configuration item (NIST SP 800-128 / CNSSI 4009-2015) is "an aggregation of information system components designated for configuration management and treated as a single entity in the configuration management process." Version control operates at the level of the configuration item.

A baseline — defined by NIST SP 800-160v1r1 as "a formally approved version of a configuration item at a specific lifecycle point" — is what version control produces and protects: a known-good reference state that can be restored or audited.

Mental model

Think of version control as a timestamped ledger for a configuration item. Every entry records: what changed, when it changed, who changed it, and what it looked like before. The ledger is append-only; nothing is silently overwritten. This means you can always answer three security-critical questions: "What is the current authorised state?", "Has anything deviated from it?", and "Who is responsible for each change?"

That accountability property is formal. NIST SP 800-12 Rev. 1 defines accountability as "the security goal that generates the requirement for actions of an entity to be traced uniquely to that entity," and notes it supports "non-repudiation, deterrence, fault isolation, intrusion detection and prevention, and after-action recovery." Version control is a primary mechanism that delivers accountability for changes to configuration items.

When to use it

Version control is often confused with change management. They are complementary but distinct:

Dimension	Version control	Change management
Primary purpose	Record and retrieve every state of a configuration item	Govern the approval process before a change is applied
When it acts	Continuously — on every committed change	Before a change is implemented (request → review → approve → implement)
What it produces	A history of item states (baselines, diffs, rollback points)	An authorisation record (tickets, approval signatures, implementation windows)
Security property delivered	Integrity and accountability of artifacts	Authorisation and traceability of decisions
Exam trigger phrase	"track changes to code/config", "restore previous state", "audit who changed what"	"approval board", "authorised change", "change request", "impact analysis"

A practitioner uses change management to get permission to act and uses version control to record what was done. Both can be present simultaneously; they solve different problems.

Integrity (NIST SP 800-152) is the data-protection goal that data "has not been altered in an unauthorized manner since it was created, transmitted, or stored." Version control supports this goal by maintaining a baseline — a formally approved reference state — and producing an audit trail (CNSSI 4009-2015: "a chronological record that reconstructs and examines the sequence of activities surrounding or leading to a specific operation") that makes unauthorised alteration detectable.

COMMON MISCONCEPTION

The most common trap is treating version control as a backup mechanism rather than an integrity and accountability mechanism. Backups preserve copies for recovery; version control preserves the history of authorised change so that any deviation from an approved baseline can be detected and attributed.

A related misconception is that version control only applies to source code. The NIST definition of a configuration item explicitly includes hardware, software, databases, and documentation. Any configuration item managed under NIST SP 800-128 principles is a candidate for version control, not just software repositories.

A third misconception conflates version control with change management: candidates sometimes select "version control" when a question asks who approved a change, or select "change management" when a question asks about recording or reverting a change. The approval authority lives in change management; the historical record lives in version control.

How it shows up on the exam

The cognitive target is analysis: given a security scenario, identify whether the control needed is one that tracks and preserves states (version control) or one that authorises and governs changes (change management).

Signal phrases that point toward version control:

• "audit who modified the configuration"
• "revert to the last known-good state"
• "detect unauthorised changes to files or configurations"
• "maintain a record of all changes made to source code"
• "establish a baseline and track deviations"

Candidates often miss that restoring a baseline (a formally approved version of a configuration item, per NIST SP 800-160v1r1) is a version-control function. If a question describes an organisation that needs to re-establish the integrity of a system after suspected tampering, the answer will involve restoring an approved baseline — which is enabled by version control, not by the change-management process alone.

The accountability definition (NIST SP 800-12 Rev. 1) is also a signal: when a question asks how an organisation can ensure that changes "may be traced uniquely" to the individual who made them, version control is the mechanism providing that traceability in the context of configuration items.

Related concepts

• Change Management — the complementary governance process that authorises changes before they are applied; works alongside version control rather than replacing it.
• Change Impact Analysis — the evaluation of consequences before a change is approved; feeds into the change management process and informs which configuration items need version-controlled baselines.
• Security Control Categories — version control is a technical and operational control; understanding control categories helps place it correctly in a defence-in-depth architecture.