Investigation evidence lifecycle
Treat evidence as a controlled lifecycle: identify, collect, preserve, examine, analyze, and report it while maintaining integrity and traceability.
Layer by Layer
Confidence by Practice
Preparing your CISSP domains…
Layer by Layer
Confidence by Practice
Preparing your CISSP domains…
Read knowledge points freely. Practice, saved topics, progress and personal records require sign-in.
349 knowledge points
Treat evidence as a controlled lifecycle: identify, collect, preserve, examine, analyze, and report it while maintaining integrity and traceability.
Document who collected, transferred, stored, accessed, and returned or disposed of evidence, with times and purposes, so possession is traceable.
Use cryptographic hashes to demonstrate that an acquired evidence image or file has not changed since collection; preserve the original and verify copies.
A forensic image is a controlled copy made for examination so analysis can occur without modifying the original evidence.
A bit-stream image captures addressable media content at the lowest practical level, including data beyond ordinary active files when the acquisition method supports it.
Logical acquisition collects selected files, objects, or records through the operating system or application interface and may omit unallocated or deleted data.
Use live acquisition when volatile evidence or system state would be lost on shutdown, while documenting that collection itself can alter the running system.
Prioritize more volatile evidence before less volatile evidence when delay would cause relevant data to disappear.
Memory forensics examines volatile memory for processes, credentials, network state, injected code, and other runtime artifacts that may not exist on disk.
Network forensics analyzes packet, flow, session, and infrastructure records to reconstruct communications and attacker activity.
Host forensics correlates operating-system, file-system, registry/configuration, process, and application artifacts from an endpoint or server.
Mobile-device forensics must account for device locks, encryption, cloud synchronization, radios, app containers, and the risk of remote alteration.
Cloud forensics depends heavily on provider logs, snapshots, API records, tenant boundaries, legal authority, and preservation actions because the examiner may not control physical media.
A write blocker helps prevent a forensic workstation from modifying source media during acquisition when the medium and workflow support write blocking.
Perform examination on verified working copies when practicable and preserve the original evidence in a controlled state.
Preservation prevents avoidable alteration, loss, contamination, or destruction of potentially relevant evidence after identification.
A legal hold suspends normal deletion or disposal for information that may be relevant to litigation, investigation, or regulatory obligations.
Investigators should collect and document evidence in a manner consistent with applicable legal, regulatory, contractual, and organizational requirements; technical relevance alone does not guarantee admissibility.
Confirm the investigator has authority and scope before accessing systems, accounts, communications, or data; excessive collection can create legal and privacy exposure.
Build a timeline by normalizing timestamps and correlating artifacts across sources; account for clock skew, time zones, and inconsistent time semantics.
Correlate multiple independent artifacts before drawing strong conclusions because any single log or artifact may be incomplete, manipulated, or ambiguous.
Record tools, versions, settings, commands, collection times, hashes, decisions, and deviations sufficiently for another qualified person to understand or reproduce the process.
Use tools that are appropriate for the evidence source and validate or corroborate critical results rather than assuming a tool output is infallible.
Limit unnecessary access and transformations of evidence; every handling step should have a defined purpose and be documented.
A defensible report distinguishes observed facts, methods, assumptions, limitations, and analyst conclusions rather than presenting inference as raw evidence.
Forensic evidence may establish what occurred without proving ultimate root cause; avoid overstating causal certainty.
Collect enough evidence to satisfy the investigation purpose while limiting unrelated personal or sensitive data when law and policy require minimization.
Retain evidence and supporting records for the period required by legal, regulatory, contractual, investigative, and organizational needs, then dispose of them securely.
Forensic readiness means designing logging, time synchronization, retention, access, and procedures in advance so investigations can obtain reliable evidence efficiently.
When evidence is held by a cloud provider, carrier, vendor, or other third party, preservation and acquisition depend on contractual capability, legal process, and provider procedures.
A data artifact is information relevant to an investigation, such as file content, metadata, database records, application records, or recovered data; preserve context and provenance when collecting it.
Computer-system artifacts include operating-system, file-system, process, configuration, account, event, and application evidence from a host; interpret them in system context.
Manage log data across generation, transmission, storage, access, analysis, retention, and disposal according to security and compliance needs.
Centralize security-relevant logs where practical to improve correlation, retention control, access control, and resilience against local tampering.
Synchronize system clocks to a trusted time source and monitor drift so events from different systems can be correlated reliably.
Select log sources based on risk and use cases, including identity, endpoint, network, application, cloud, database, security control, and administrative activity.
Normalize heterogeneous log fields and timestamps into consistent semantics before correlation while preserving the original event data when needed.
Enrich events with context such as asset criticality, identity, vulnerability, geolocation, ownership, and threat intelligence to improve prioritization.
Protect logs from unauthorized modification or deletion through access controls, secure transport, integrity mechanisms, restricted administration, and resilient storage.
Logs may contain credentials, identifiers, content, or sensitive operational details and therefore require appropriate confidentiality and access controls.
Define log retention from investigation, regulatory, operational, privacy, and cost requirements rather than keeping all data indefinitely by default.
A SIEM centralizes and analyzes security events, correlates data across sources, and supports alerting, investigation, reporting, and retention workflows.
A correlation rule combines multiple events, conditions, or context to identify a pattern that is more meaningful than isolated events.
Tune detection logic using environment-specific baselines, false-positive analysis, asset context, and threat changes while avoiding suppression of meaningful signals.
Excessive low-value alerts reduce analyst attention and can hide important events; improve fidelity through tuning, prioritization, deduplication, and workflow design.
A false positive is an alert for benign activity; reducing false positives improves efficiency but overly aggressive suppression can increase missed detections.
A false negative occurs when malicious or policy-violating activity is not detected; detection quality must consider both missed events and false alarms.
A baseline describes expected behavior or configuration so deviations can be evaluated; baselines must be maintained as the environment changes.
Continuous monitoring repeatedly observes security-relevant state and activity so changes and risk can be identified in a timely manner; it does not imply literally zero delay.
Egress monitoring observes outbound communications and data movement to identify exfiltration, command-and-control, policy violations, and unexpected external dependencies.
A network IDS observes network traffic and generates detections but normally does not sit inline to block traffic by itself.
A network IPS operates inline or otherwise has enforcement capability to block, drop, reset, or rate-limit traffic based on detection policy.
A host IDS monitors host-level events such as logs, files, processes, or configuration for suspicious changes or activity.
Signature-based detection matches known patterns and can be precise for known threats but may miss novel or modified activity.
Anomaly-based detection identifies deviation from expected behavior and can surface unknown activity, but requires baselining and may create more false positives.
Threat intelligence is analyzed information about threats, actors, infrastructure, vulnerabilities, tactics, or indicators that is made relevant to a decision or defense use case.
A raw threat feed supplies data such as indicators; it becomes intelligence only after analysis, context, relevance, and confidence are applied.
An IOC is observable evidence associated with malicious activity, such as a hash, domain, IP, file path, registry value, or behavior artifact; indicators can become stale or be spoofed.
TTP-oriented intelligence describes adversary behavior and objectives and is often more durable than individual infrastructure indicators.
Threat hunting is a hypothesis- or intelligence-driven proactive search for adversary activity that existing automated detections may not have surfaced.
A hunt hypothesis states a plausible adversary behavior or condition to test against available telemetry rather than searching without a defined question.
UEBA analyzes behavioral patterns for users and entities to identify unusual activity, often using peer groups, baselines, risk scoring, or statistical/ML methods.
Behavior analytics can flag anomalies but does not by itself prove malicious intent; investigation and context remain necessary.
SOAR coordinates security tools and workflows, automates repeatable steps, and supports case response; high-impact actions should have appropriate authorization and safeguards.
AI can summarize, cluster, prioritize, and enrich security telemetry, but analysts must account for model error, incomplete context, adversarial input, and the impact of automated actions.
The greater the potential business or safety impact of an automated response, the stronger the need for bounded authority, approvals, rollback, auditability, and human oversight.
Behavioral or ML detections can degrade as systems, users, or adversaries change; monitor performance and retrain or retune when the baseline shifts.
Attackers may intentionally shape inputs to evade ML-based detections, so AI-based tools require layered controls and validation rather than blind trust.
Configuration management establishes and maintains the integrity of systems and products by controlling how configurations are initialized, changed, and monitored throughout the lifecycle.
Security-focused CM integrates security requirements into configuration baselines, change control, monitoring, and assessment to reduce risk while preserving required functionality.
A configuration baseline is a formally defined and approved set of configuration characteristics used as the reference for future changes and drift detection.
A secure baseline contains approved security-relevant settings appropriate to the system role, risk, and environment and should be versioned and maintained.
A configuration item is a component, artifact, or controlled element whose identity and state are managed under configuration control.
Maintain an accurate inventory of managed hardware, software, firmware, services, dependencies, and relevant versions so configuration state can be controlled.
Configuration drift is unauthorized or unintended deviation from the approved baseline; detect, investigate, and reconcile drift.
Automated or periodic comparisons against known-good baselines can identify configuration drift; alerts still require context to distinguish authorized exceptions.
Version controlled configuration artifacts make changes attributable, reviewable, reproducible, and reversible.
Configuration documentation should identify approved settings, owners, rationale, dependencies, exceptions, and recovery or rollback information.
Automation can continuously apply approved configuration and reduce variance, but automation itself must be access-controlled, versioned, tested, and monitored.
Infrastructure as Code expresses infrastructure configuration in versioned machine-readable artifacts, improving repeatability and review while creating a need to secure the code and pipeline.
Desired-state management compares actual state with declared approved state and corrects or reports divergence according to policy.
A configuration exception is a documented and approved deviation from baseline with risk rationale, scope, compensating controls, owner, and review/expiration conditions.
A golden image is an approved standardized system image used to deploy consistent known configurations; it must be maintained and updated, not treated as permanently trusted.
Immutable infrastructure replaces deployed instances with newly built approved versions rather than modifying them in place, reducing drift but requiring strong build and artifact controls.
Plan and test rollback for configuration changes so a failed or harmful change can be reversed without improvisation.
A configuration audit compares documented and approved state with actual state and evaluates whether configuration controls are operating as intended.
Restrict who can modify configuration baselines, repositories, deployment systems, and production settings; privileged CM paths are high-value targets.
Configuration management maintains controlled state and integrity; change management governs the authorization, risk, scheduling, testing, and communication of proposed changes.
Provision systems from approved, versioned configurations and images so new instances begin in a known controlled state rather than relying on ad hoc manual setup.
Need-to-know limits access to information required for an authorized task even when a person otherwise holds a clearance, role, or general entitlement.
Common traps: A person can satisfy one principle and still violate the other; clearance or role membership alone does not establish need-to-know.
Least privilege grants only the permissions and duration necessary to perform an authorized function and removes excess privilege when no longer needed.
Common traps: A person can satisfy one principle and still violate the other; clearance or role membership alone does not establish need-to-know.
Separation of Duties divides critical tasks among multiple roles or people so one individual cannot complete a high-risk process alone.
Dual control requires two authorized individuals to act together for a sensitive operation; it is one implementation of separation-of-duties concepts.
Split knowledge divides sensitive information so no single individual possesses the complete secret required for a protected operation.
Job rotation periodically changes duties to reduce dependence on one person, expose concealed irregularities, broaden skills, and improve resilience.
Mandatory vacation can expose fraud or unsafe dependency by requiring another person to perform the absent employee's duties for a meaningful period.
A privileged account can perform high-impact administrative or security actions and therefore requires stronger control, monitoring, and accountability than ordinary access.
PAM manages privileged credentials and sessions through controls such as vaulting, approval, just-in-time access, session recording, rotation, and policy enforcement.
Monitor or record high-risk privileged sessions where appropriate to support deterrence, investigation, and accountability while protecting sensitive session data.
Shared privileged accounts weaken individual accountability; prefer uniquely attributable identities and controlled emergency/shared use when unavoidable.
A break-glass account provides emergency privileged access when normal mechanisms fail; tightly protect, monitor, test, and review every use.
Just-in-time privilege grants elevated access only when needed and for a limited period, reducing standing privilege exposure.
An SLA documents measurable service commitments, responsibilities, and remedies or escalation expectations between service parties.
Security-relevant SLAs can define response time, patch time, availability, logging, notification, support, recovery, or other measurable security obligations.
Each operational control or service should have a defined owner accountable for decisions, maintenance, exceptions, and escalation.
A runbook documents repeatable operational steps, decision points, prerequisites, evidence, escalation, and rollback for a defined task or incident.
Policy states required intent and constraints; operational procedures describe the repeatable steps used to implement those requirements.
Define escalation paths and authority so unresolved or high-impact operational issues reach the right technical and business decision makers promptly.
Shift and team handoffs should transfer current incidents, risks, pending actions, exceptions, and ownership explicitly to avoid loss of context.
Need-to-know limits which information an authorized person may access for a task, while least privilege limits the permissions or capabilities granted and their duration; both may apply at the same time but control different dimensions.
Media management controls the inventory, use, storage, transport, reuse, retention, sanitization, and disposal of physical and logical media.
Track sensitive or high-value media with identifiers, custodianship, location, status, and lifecycle state appropriate to risk.
Apply labels or metadata that support correct handling without unnecessarily exposing sensitive content to unauthorized observers.
Restrict and monitor removable media based on business need and risk; controls may include authorization, scanning, encryption, device control, and blocking.
Protect sensitive media in transit using appropriate packaging, custody, tracking, encryption, and approved carriers or personnel.
Store media in environments and containers that protect confidentiality, integrity, availability, and physical condition according to classification and risk.
Sanitization renders data infeasible to access at a level appropriate to the media, sensitivity, reuse/disposal decision, and threat model.
Clearing uses logical techniques for ordinary reuse, purging applies stronger techniques against advanced recovery, and destruction physically renders media unusable; choose by risk and media capability.
Data remanence is residual representation of data after nominal deletion or erasure; sanitization decisions must account for it.
Encryption at rest reduces disclosure risk if storage is lost or accessed without authorization, but key management and authorized endpoint access remain critical.
Encryption in transit protects data across untrusted or exposed communication paths and should include appropriate peer authentication and integrity protection.
Protect encryption keys separately from encrypted media or backups so loss of the media does not automatically provide the means to decrypt it.
Backup media contains production information and must receive equivalent or stronger confidentiality, integrity, access, retention, and physical protection.
Before reassigning media to a different trust level or owner, sanitize it to the level required by the previous data sensitivity and media type.
For sensitive media disposal, retain evidence such as certificates, logs, witnesses, or destruction records when required by policy or compliance.
Treat incident response as an organization-wide risk management capability spanning preparation, detection, response, recovery, and improvement rather than a standalone SOC activity.
Detection identifies potentially adverse cybersecurity events from telemetry, reports, intelligence, or control signals and initiates analysis.
Triage validates an event, determines likely scope and impact, gathers essential context, and sets response priority.
Define criteria and authority for declaring an incident so the appropriate response structure, communications, and obligations are activated consistently.
Severity should reflect business impact, scope, criticality, safety, legal/regulatory exposure, data sensitivity, and adversary capability rather than a single technical indicator.
Containment limits ongoing damage or spread while preserving required evidence and business capability; containment choices should reflect operational impact.
Common traps: Do not treat every post-detection action as interchangeable incident response; sequence and objective determine the best answer.
Short-term containment rapidly limits immediate harm, often with temporary isolation or blocking, while longer-term remediation is prepared.
Eradication removes the attacker's artifacts, persistence, malicious code, compromised credentials, or exploited weaknesses after the incident is understood sufficiently.
Common traps: Do not treat every post-detection action as interchangeable incident response; sequence and objective determine the best answer.
Mitigation reduces incident likelihood, impact, or ongoing harm through technical, procedural, or business controls; it may be temporary or permanent.
Common traps: Do not treat every post-detection action as interchangeable incident response; sequence and objective determine the best answer.
Recovery restores affected services and business operations to an acceptable trusted state while monitoring for recurrence and validating control effectiveness.
Common traps: Do not treat every post-detection action as interchangeable incident response; sequence and objective determine the best answer.
Remediation corrects underlying vulnerabilities, control weaknesses, process failures, or design issues that contributed to the incident.
Common traps: Do not treat every post-detection action as interchangeable incident response; sequence and objective determine the best answer.
Incident reporting communicates required facts, impact, status, actions, and decisions to authorized internal and external stakeholders according to policy and obligations.
Notification obligations can have specific triggers, content, recipients, and deadlines; coordinate legal, privacy, compliance, and incident teams rather than improvising.
Use controlled communications channels and a defined communications plan; assume compromised systems or accounts may be untrustworthy during a serious incident.
Out-of-band communication provides an alternate trusted channel when primary collaboration, identity, email, or network systems may be compromised or unavailable.
Define incident roles, decision authority, escalation, technical leads, communications, legal/compliance support, and executive ownership before a crisis.
Response actions should preserve relevant evidence when feasible without allowing evidence collection to override urgent life-safety or major business-impact decisions.
Continuously reassess scope because initial indicators often represent only part of the affected environment or attack path.
When credentials are compromised, sequence resets and recovery so attackers cannot immediately recapture new credentials through still-compromised systems or identity paths.
Restore systems from verified clean sources and known-good configuration rather than returning a compromised state to production.
After stabilization, identify what happened, what worked, what failed, and which controls, plans, detections, training, or architecture should change.
Root-cause analysis seeks contributing technical and organizational causes, not merely the first observable failure, and should drive corrective action.
Useful incident metrics measure outcomes and process performance such as detection, containment, recovery, recurrence, backlog, and control improvement rather than rewarding alert volume alone.
During active ransomware, rapidly limiting propagation and protecting unaffected backups or recovery infrastructure can take priority over keeping every endpoint online.
Automate repeatable low-risk response actions where appropriate, but bound credentials, blast radius, approvals, logging, and rollback for actions that can disrupt production.
Treat AI-generated investigation or response recommendations as analyst input, not authoritative fact; validate evidence, assumptions, and proposed high-impact actions.
Coordinate technical response, business decisions, communications, legal/compliance obligations, evidence needs, and recovery work under defined authority so actions do not conflict.
A packet-filter firewall makes decisions primarily from packet header attributes and rules; it has less application context than higher-layer controls.
A stateful firewall tracks connection state so policy decisions can account for whether traffic belongs to an established or expected session.
An NGFW combines traditional firewalling with deeper application/user awareness and may integrate intrusion prevention, TLS inspection, URL filtering, or threat controls.
A WAF inspects HTTP/S application traffic to detect or block web-layer attacks; it does not replace secure application design or general network firewalls.
Where a firewall evaluates rules in sequence, rule order can change the effective policy; test for shadowed, overly broad, and conflicting rules.
A default-deny posture permits explicitly authorized traffic and rejects unmatched traffic, reducing unintended exposure compared with broad default allow.
Outbound firewall policy can restrict unexpected destinations, protocols, and data paths and supports egress monitoring and containment.
IDS primarily detects and alerts; IPS has enforcement capability to prevent or disrupt traffic. Placement and failure behavior differ because IPS can affect availability.
Signature-based sensors require timely signature/content updates and testing because outdated signatures miss threats while poor signatures can create noise or disruption.
Network sensors cannot inspect encrypted payload content unless traffic is decrypted at an appropriate control point; metadata and endpoint telemetry may still provide visibility.
Allowlisting permits only approved code, destinations, senders, or actions and can strongly reduce attack surface, but requires lifecycle maintenance and exception control.
Denylisting blocks known prohibited items but allows unmatched items, making it easier to operate but less effective against unknown threats than strict allowlisting.
Application allowlisting restricts execution to approved software or code identities and is especially useful on stable high-value systems.
A sandbox executes or opens untrusted content in an isolated or restricted environment to observe behavior and limit impact; sophisticated malware may detect or evade sandboxes.
A honeypot is a decoy system or service intended to attract, detect, or study unauthorized activity and must be isolated so it does not become a launch point.
A honeynet is a network of decoy systems that provides richer attacker interaction and telemetry than a single honeypot but requires careful containment.
Deception controls create decoy identities, credentials, files, services, or systems to increase attacker cost and generate high-signal detections.
Anti-malware uses signatures, heuristics, reputation, behavior, and other techniques to detect, block, quarantine, or remove malicious code.
EDR collects endpoint telemetry and supports behavioral detection, investigation, and response actions such as isolation or process termination.
Quarantine isolates a suspected malicious file, message, host, or workload to prevent normal interaction while retaining it for analysis or controlled recovery.
A third-party security service can provide monitoring, detection, response, or control operations, but accountability, access, telemetry, SLAs, escalation, and evidence responsibilities must be defined.
Managed Detection and Response (MDR) combines externally operated detection, investigation, and response capabilities; the customer still retains governance and risk ownership.
Monitor attempts to disable, evade, uninstall, or tamper with security tools because control impairment can be a high-value detection signal.
Choose fail-open or fail-closed behavior based on the security and availability consequences of a control failure; neither is universally correct.
Combine network, endpoint, identity, application, cloud, and data telemetry so attackers must evade multiple independent detection layers.
AI-based detections should be validated against representative data, monitored for drift and bias, and combined with deterministic or human controls for high-impact decisions.
Treat external text, logs, tickets, emails, or incident artifacts supplied to SOC copilots as untrusted input because malicious content can influence AI-generated analysis or actions.
Enterprise patch management identifies, prioritizes, acquires, installs, and verifies patches, updates, and upgrades as preventive maintenance and risk reduction.
Know affected assets, software, firmware, versions, and ownership so patch applicability and deployment status can be determined accurately.
Prioritize remediation using vulnerability severity together with exploitability, active exploitation, asset exposure, business criticality, compensating controls, and mission impact.
CVSS describes technical severity characteristics but does not by itself determine organizational remediation priority or business risk.
Test patches against representative systems and critical functions before broad deployment when feasible, while balancing test time against exploitation risk.
Emergency patching uses expedited assessment, approval, testing, deployment, monitoring, and rollback for urgent risk; it should be controlled rather than bypassing governance entirely.
Prepare and test rollback or recovery paths before high-risk patch deployment when practical because patches can cause functional or availability failures.
Verify successful installation and resulting system state rather than assuming deployment tooling guarantees that a patch is active everywhere.
Document and approve patch exceptions with risk rationale, compensating controls, owner, scope, and review or expiration date.
When a patch cannot be applied promptly, reduce exposure through controls such as isolation, disabling vulnerable functionality, access restriction, WAF/IPS rules, or enhanced monitoring.
Vulnerability management continuously discovers, validates, prioritizes, remediates or accepts, verifies, and tracks vulnerabilities and exposure.
Authenticated scanning can inspect local configuration and patch state more deeply than unauthenticated external probing, but credentials and scanner privileges must be protected.
Unauthenticated scanning approximates what a network-visible attacker can observe without valid credentials but has less internal configuration visibility.
Validate high-impact scan findings before disruptive remediation because scanner results can be inaccurate or lack environmental context.
Exposure management considers vulnerabilities together with reachable attack paths, identities, misconfigurations, business context, and compensating controls rather than patch status alone.
Unsupported or end-of-life technology may no longer receive security fixes; reduce, isolate, replace, or formally accept the risk rather than treating it as normally patchable.
Firmware and device updates require inventory, authenticity verification, compatibility testing, maintenance planning, and rollback/recovery appropriate to device constraints.
Obtain updates from trusted sources and verify signatures, hashes, package metadata, or platform authenticity mechanisms before deployment.
A maintenance window coordinates expected service impact and staffing but does not justify delaying an actively exploited critical vulnerability without risk-based treatment.
Measure meaningful outcomes such as exposure age, coverage, exceptions, failed deployments, critical remediation time, and recurrence instead of reporting only patch counts.
Change management governs the request, assessment, authorization, scheduling, testing, implementation, communication, documentation, and review of changes.
A change request defines the proposed change, business reason, affected assets, owner, risk, dependencies, implementation plan, test plan, and backout plan as appropriate.
Assess security, availability, operational, compliance, dependency, and rollback risk before approving a material change.
Authorized decision makers approve changes according to risk and scope; the implementer should not unilaterally approve high-risk changes without governance.
A change board reviews material changes for cross-functional impact, risk, scheduling, conflict, and readiness; not every routine standard change requires the same board process.
A standard change is low-risk, repeatable, well-understood, and pre-authorized under defined conditions; deviations should leave the standard path.
A normal change follows the ordinary risk assessment and approval workflow appropriate to its impact and complexity.
An emergency change uses an expedited but documented authorization path for urgent risk or outage and requires subsequent review; urgency does not eliminate accountability.
Test changes in a representative nonproduction environment when feasible and define success criteria before production implementation.
A backout plan defines how to return to a known acceptable state if the change fails or causes unacceptable impact.
Schedule changes to balance business impact, staffing, dependencies, recovery capability, and urgency rather than choosing time solely for administrator convenience.
A change freeze temporarily restricts nonessential changes during high-risk periods; emergency security changes may still proceed through an authorized exception process.
Review significant changes after implementation to confirm objectives, detect unintended effects, document incidents, and improve future change practices.
Compare actual state with approved changes and configuration baselines to identify undocumented or unauthorized modifications.
Separate request, approval, implementation, and validation roles for high-risk changes where practical to reduce fraud and error.
Before a material change, determine whether threat surface, identities, trust boundaries, logging, data flows, dependencies, or compliance assumptions are altered.
Update system diagrams, inventories, baselines, runbooks, recovery procedures, support information, and security documentation when a change makes them stale.
RTO is the target time to restore a service or function after disruption; it drives recovery strategy but is not the same as maximum tolerable downtime.
RPO is the maximum targeted data-loss interval measured backward from disruption; it drives backup or replication frequency.
MTD is the maximum disruption duration the business can tolerate before unacceptable impact; recovery objectives should fit within that limit.
WRT is the time after technology restoration needed to validate, reconcile, and resume the business process; RTO plus WRT should fit within business tolerance.
A full backup copies the selected data set and provides the simplest restore chain but consumes more backup time and storage.
An incremental backup captures changes since the most recent backup in the backup chain, typically the last full or incremental backup. It reduces each backup set but restoration generally requires the last full backup plus every subsequent incremental backup.
A differential backup captures changes since the last full backup; restore generally needs the full backup plus the latest differential.
A snapshot records storage or system state at a point in time and can provide fast recovery, but a snapshot on the same failure domain is not automatically an independent backup.
Common traps: Do not assume a snapshot or replica is automatically an independent backup.
Replication maintains copies on another system or site and can reduce RPO/RTO, but corruption or malicious deletion may replicate unless protection and recovery points exist.
Common traps: Do not assume a snapshot or replica is automatically an independent backup.
Synchronous replication commits data to multiple locations before completion, providing very low data loss but adding latency and distance constraints.
Asynchronous replication acknowledges local writes before remote copies complete, improving distance/performance flexibility but allowing a nonzero data-loss window.
An immutable backup cannot be altered or deleted through ordinary administrative paths for a defined retention period, helping resist ransomware and malicious deletion.
Offline backups are disconnected from normal systems when not in use, reducing exposure to online compromise but increasing operational handling requirements.
An air-gapped backup is isolated from normal network paths; true isolation requires considering management networks, credentials, automation, and physical connectivity.
Encrypt backups containing sensitive data and protect the keys, recovery credentials, and metadata so backups remain usable but not casually readable.
A backup is not proven usable until restore procedures are tested and data/application consistency is validated.
Offsite backup reduces exposure to a local disaster; the offsite location must still meet security, access, retention, and recovery-time requirements.
Cloud backup can provide geographic separation and elastic storage but requires control of identity, encryption, provider dependency, egress/recovery bandwidth, and contractual availability.
A hot site has infrastructure and systems sufficiently ready for rapid activation, giving low recovery time at higher cost.
A warm site has partial infrastructure and resources but requires additional configuration, data restoration, or activation before full operation.
A cold site provides basic facility capacity with limited preinstalled technology, giving lower cost but longer recovery time.
A reciprocal agreement allows organizations to support each other during disruption, but capacity, compatibility, security, priority, and simultaneous-disaster risks can make it unreliable.
Distribute processing across multiple sites to reduce dependence on one location; architecture and data consistency determine whether failover is active-active or active-passive.
Active-active systems serve workload from multiple nodes or sites simultaneously, improving availability but increasing synchronization and failure-mode complexity.
Active-passive systems keep standby capacity ready to take over from the active system; failover time and state synchronization determine recovery characteristics.
High availability minimizes service interruption through redundancy, failover, monitoring, and operational design; HA does not eliminate the need for backups or disaster recovery.
Fault tolerance allows a system to continue operating despite specified component failures, typically through redundancy and automatic error handling.
Resilience is the ability to withstand, adapt to, recover from, and continue or restore operations after adverse conditions.
Redundancy duplicates components, paths, capacity, or sites to reduce single points of failure, but common-mode dependencies can defeat nominal redundancy.
A single point of failure is a component or dependency whose loss causes unacceptable service failure; identify both obvious and hidden dependencies.
QoS prioritizes and manages network resources so critical traffic receives required performance during congestion; it supports availability but is not disaster recovery by itself.
Recovery contracts should specify usable capacity, activation priority, testing rights, dependencies, and resource contention so promised capacity is realistic during widespread events.
Map upstream and downstream dependencies such as identity, DNS, network, certificates, secrets, data, vendors, facilities, and staff before setting recovery sequence.
Restore services according to business criticality, dependency order, safety, regulatory needs, and recovery objectives rather than technical convenience alone.
Define who can activate the DR plan and the criteria for declaring a disaster or invoking alternate recovery arrangements.
Initial DR response protects life and safety, stabilizes the environment, activates governance, and coordinates transition to recovery activities.
Assign named roles and alternates for command, technical recovery, facilities, communications, vendors, business units, and executive decisions.
Maintain current primary and alternate contact methods for staff, vendors, authorities, customers, and other recovery stakeholders.
A DR communications plan defines audiences, approved messages, channels, owners, update frequency, and fallback methods during disruption.
Assess physical, technical, data, dependency, and business impact before selecting restoration actions and site strategies.
Activate recovery in dependency-aware order so foundational services such as power, network, identity, DNS, storage, and key systems are available when dependent applications start.
Alternate-site procedures should define access, authentication, networking, data availability, capacity, staffing, security, and transition steps.
After technical restoration, validate security, data consistency, application function, integrations, monitoring, and business acceptance before declaring normal operation.
Failback returns operations from the recovery environment to the primary or new steady-state environment using a controlled plan that protects data and availability.
Personnel need role-specific DR training before an emergency so they understand authority, procedures, communications, and safety expectations.
Broader staff awareness ensures employees know how to report disruptions, receive instructions, evacuate or relocate, and avoid interfering with recovery.
Update DR plans when systems, sites, vendors, contacts, dependencies, recovery objectives, or lessons learned change.
After tests or real disasters, document gaps, assign corrective actions, track them to closure, and update plans and architecture.
Recovery dependencies on telecom, cloud, hardware, facilities, logistics, and other vendors require current contacts, contracts, priorities, and tested procedures.
Recovery environments require appropriate security controls; do not remove authentication, logging, segmentation, or access governance simply because operations are in emergency mode.
Recovery may require rapid changes, but emergency authorization, documentation, logging, and later review should remain in place.
Provide decision makers with concise status on service availability, data loss, blockers, risks, estimates, dependencies, and next decisions.
Keep recovery procedures and essential credentials or access methods available through protected alternate means because primary repositories may be unavailable.
Define objective criteria for ending disaster mode and returning to normal governance, staffing, monitoring, and business operations.
A read-through or checklist review verifies that plan content, contacts, steps, and references are current without exercising operational recovery.
A tabletop exercise walks decision makers through a simulated disruption and discusses actions, decisions, communications, and gaps without executing full technical recovery.
A walkthrough has participants step through procedures and locations in greater operational detail than a tabletop, often validating responsibilities and resources without full interruption.
A simulation recreates selected disaster conditions and response activities in a controlled manner without intentionally interrupting the primary production environment.
A parallel test activates recovery systems and processes while production continues, allowing validation with lower business interruption risk.
A full-interruption test deliberately stops or transfers production to prove end-to-end recovery and carries the highest operational risk.
Define specific test objectives tied to recovery capabilities, RTO/RPO, communication, staffing, dependencies, or procedures before selecting the exercise method.
Control exercise scope so tested services, sites, data, vendors, and excluded areas are explicit and stakeholders understand expected impact.
Establish measurable success and stop criteria before the exercise so results are evaluated consistently.
Exercises must not create unacceptable safety, regulatory, customer, or production risk; include abort and rollback authority.
Inform appropriate stakeholders of test status and clearly distinguish exercise messages from real incident messages while preserving realism.
Capture timings, decisions, failures, workarounds, logs, observations, and achieved recovery points so objectives can be evaluated.
Convert exercise findings into owned corrective actions with due dates, priorities, retesting, and plan updates.
Set exercise frequency based on risk, regulatory requirements, material changes, service criticality, and prior deficiencies rather than using one universal interval.
Mature programs often progress from lower-risk discussion exercises to increasingly realistic technical and operational tests as readiness improves.
Business continuity keeps critical business functions operating at an acceptable level during disruption and coordinates continuity strategies beyond IT recovery alone.
BC strategies should be driven by BIA results such as critical processes, dependencies, impact over time, recovery priorities, and tolerable disruption.
A critical business process is prioritized because its disruption creates unacceptable mission, financial, legal, safety, customer, or reputational impact within the relevant time horizon.
A manual workaround can sustain a critical process when technology is unavailable, but capacity, accuracy, staffing, security, and reconciliation limits must be understood.
Continuity may use alternate offices, remote work, distributed teams, or third-party facilities; connectivity, security, equipment, privacy, and staffing must be planned.
Map dependencies on people, facilities, technology, data, utilities, suppliers, logistics, and other business processes to avoid unrealistic continuity assumptions.
Identify minimum staffing, alternates, cross-training, succession, remote capability, and constraints for critical processes during disruption.
Continuity planning includes reliable methods to communicate with employees, customers, suppliers, regulators, and leadership when normal channels are degraded.
BC exercises validate business decision making, workarounds, staffing, dependencies, communications, and coordination—not only technical system recovery.
Business continuity focuses on sustaining critical business operations; disaster recovery focuses more specifically on restoring technology and supporting infrastructure.
Crisis management coordinates executive decisions, safety, communications, reputation, legal obligations, and strategic response during a major disruptive event.
Critical suppliers require continuity expectations, alternate options, escalation paths, geographic concentration review, and evidence that contracted recovery capabilities are realistic.
Update continuity plans after organizational, process, technology, supplier, facility, staffing, regulatory, or lessons-learned changes.
When resources are scarce, recovery priorities should follow approved business criticality and safety needs rather than the loudest stakeholder or highest technical rank.
Layer perimeter, building, room, rack, device, environmental, detection, and response controls so failure of one barrier does not expose critical assets directly.
During operations, monitor changes in natural hazards, utilities, crime, transportation, neighboring hazards, communications, and emergency-service availability around a critical facility, and escalate or adjust controls when the risk changes. Initial site selection is primarily a Domain 3 design decision.
Fences define and delay access to a controlled perimeter; effectiveness depends on height, construction, gates, lighting, detection, and response.
Bollards create vehicle standoff and can reduce vehicle-ramming or accidental vehicle impact risk around protected facilities.
Security lighting deters, supports observation, and improves camera or guard effectiveness but should avoid glare, shadows, and uncontrolled exposure.
CCTV provides surveillance, deterrence, and investigative evidence; camera placement, coverage, lighting, retention, integrity, privacy, and monitoring determine value.
Guards provide judgment, deterrence, response, visitor handling, and exception management that purely automated controls cannot fully replace.
Badges provide identity-linked physical access decisions and should be issued, reviewed, revoked, monitored, and protected against sharing or cloning.
A mantrap or access-control vestibule uses interlocked doors and controlled authentication to reduce tailgating into sensitive areas.
Tailgating occurs when an unauthorized person follows an authorized person through a controlled entry without independently authenticating.
Piggybacking commonly refers to knowingly allowing another person to enter on one authorization; terminology varies, so policy should focus on independent authorization.
Visitors should be identified, authorized, logged, badged, escorted as appropriate, limited to approved areas, and have credentials recovered or expired.
Record entry and exit events for sensitive areas where appropriate and correlate physical access with system activity during investigations.
Door-position, forced-open, or held-open alarms detect physical control bypass but require monitoring and timely response to be effective.
Physical intrusion alarms detect unauthorized entry or movement; effectiveness depends on sensor coverage, tamper resistance, monitoring, and response.
Monitor temperature, humidity, smoke, water, power, and other environmental conditions to detect threats before they cause equipment or service failure.
Operate, monitor, maintain, and test the existing HVAC and environmental resilience for critical spaces, including alarms, capacity, redundancy, and failover; escalate emerging availability risk. Engineering selection and facility design belong primarily to Domain 3.
Use appropriate smoke, heat, or other detection technologies to identify fire early and integrate alarms with evacuation and response procedures.
Inspect, maintain, test, and monitor the installed fire-suppression system so it remains available, compliant, and compatible with current occupancy and equipment. Engineering selection of the suppression technology belongs primarily to Domain 3.
Operate and test a pre-action sprinkler by verifying its detection interlock, valves, alarms, and water path so it will activate when required without avoidable accidental discharge risk.
Operate and maintain a wet-pipe sprinkler by checking pressure, valves, leaks, obstructions, alarms, and test records so the water-filled system remains ready to function.
Operate and maintain a clean-agent suppression system by monitoring agent condition, interlocks, alarms, enclosure integrity, and life-safety procedures and by performing scheduled testing and maintenance.
Place water sensors near likely leak sources and below critical equipment areas so plumbing or cooling failures can be detected early.
Operate and maintain an Uninterruptible Power Supply by monitoring load, battery health, alarms, and bypass status and by testing that it can provide short-term conditioned power during an outage.
Operate and maintain standby generators through scheduled testing of start-up, fuel, load capability, alarms, and run records so they can carry required loads during extended utility outages.
Operate and test an automatic transfer switch so it transfers power as intended during utility loss and restoration, while monitoring interlocks, alarms, and failure modes.
Control physical keys through issuance, inventory, return, duplication restrictions, and rekeying when keys are lost or holders change.
Lock cabinets or racks containing critical equipment when room-level controls alone do not provide sufficient separation or accountability.
Before equipment leaves controlled custody, sanitize storage, remove credentials and secrets, update inventory, and document disposition as required.
Temporary physical-access exceptions should have documented scope, approver, duration, escort or compensating controls, and review.
During emergencies, protection of human life and safety takes priority over preservation of equipment, uptime, or forensic evidence.
An emergency action plan defines alarm, evacuation or shelter, accountability, emergency contacts, responsibilities, assistance, and reentry procedures.
Evacuation procedures define routes, assembly areas, mobility assistance, accountability, and conditions for leaving a threatened facility.
Shelter-in-place keeps personnel inside a protected area when external conditions make evacuation more dangerous, using predefined locations and communications.
During an emergency, account for employees, visitors, contractors, and responders using a method that does not encourage people to reenter danger.
A duress code or signal allows a person under coercion to discreetly indicate danger while appearing to comply; response procedures must be defined and tested.
A panic alarm provides rapid assistance notification for a person facing immediate threat and should be placed, monitored, and tested appropriately.
Assess destination, itinerary, local threats, medical needs, communications, data/device risk, and emergency support before high-risk travel.
For higher-risk travel, minimize carried data, accounts, and device privilege; consider clean or temporary devices and controlled reintroduction on return.
Travelers should know emergency contacts, check-in expectations, alternate communications, and how to report loss, detention, coercion, or suspicious device activity.
Insider-threat programs combine behavioral, access, HR, security, legal, and management signals under lawful governance; unusual behavior alone is not proof of malicious intent.
Security awareness should include how to recognize and report credible threats, threatening behavior, stalking, or workplace violence concerns through appropriate channels.
Personnel should understand how public posts can expose location, travel, organizational structure, technologies, incidents, routines, or sensitive context to adversaries.
MFA fatigue abuses repeated push prompts or social engineering to induce a user to approve an unauthorized authentication request.
Users should deny unexpected prompts and report them; controls such as number matching, phishing-resistant authentication, rate limits, and risk signals reduce fatigue attacks.
Use multiple independent channels for emergency notification because email, voice, collaboration, cellular, or building systems may fail together or become overloaded.
Security and IT teams should know how to coordinate with police, fire, medical, emergency management, and facility responders without obstructing life-safety operations.
Conduct drills often enough to validate routes, roles, communications, accessibility, accountability, and responder coordination while correcting observed gaps.
Emergency and security training must account for language, disability, remote workers, contractors, visitors, and other populations who may need different communication or assistance.
After traumatic incidents, organizations should account for medical, psychological, scheduling, workload, privacy, and return-to-work needs as part of sustained operations.