Not iterative in the traditional sense — data may exist in multiple phases simultaneously. Each phase has specific risks and controls.

1. 01CreateData is generated or modified. Key control: classify at point of creation; apply labels and encryption.
2. 02StoreSaved to a repository (database, file system). Controls: TLS/VPN in transit, encryption at rest, access policies, store only where classification permits.
3. 03UseViewed, processed, or modified (handling). Most active phase with the most controls: DLP, IRM, access controls, logging. Note: data states (at rest / in transit / in use) are separate from this phase.
4. 04ShareExchanged between users or systems. Controls: proactive access controls (RBAC), reactive DLP/IRM, authentication and authorisation of sharing parties.
5. 05ArchiveLong-term storage; data no longer actively used but retained for compliance or legal reasons. Controls: retention schedules, key backup (for encrypted archives), access restrictions.
6. 06DestroyPermanent deletion/sanitisation per retention policy. Method must prevent recovery by unauthorised parties (crypto-shredding, physical destruction, etc.).

The SSDLC (Secure SDLC) embeds security tasks into each phase — known as "shifting left". The NIST SSDF and OWASP SAMM are key frameworks for implementing it.

1. 01Planning (Study Guide only)Feasibility assessment, cost-benefit analysis, decision to proceed.
2. 02RequirementsBusiness, functional, and security requirements. SSDLC: document specific security requirements here (e.g. encryption at rest).
3. 03DesignArchitecture, data flows, integration points. SSDLC: threat modelling, design test cases, security architecture decisions.
4. 04Development / CodingBuild and integrate components. Includes COTS and cloud services. SSDLC: unit testing, code review, static analysis (SAST).
5. 05TestingIntegration testing, UAT, traceability to requirements. SSDLC: dynamic testing (DAST), penetration testing, abuse-case testing.
6. 06Training & Transition (Study Guide only)Also called acceptance, installation, and deployment. End-user training, go-live.
7. 07DeploymentHarden default configs, configure IAM and APIs, apply least-privilege to cloud storage services. Create standard config guides per service.
8. 08Operations & Maintenance (O&M)Longest phase. Ongoing monitoring, patching, access reviews, incident response, minor modifications.

IR frameworks share a common structure: pre-incident planning, active response, and post-incident improvement. Shared responsibility with the CSP applies — some incidents require CSP coordination, others do not.

1. 01PrepareDocument IRP and IRT, train team members, implement detection tools (SIEM, IDS). IR coordinator appointed; scenario-based response procedures written.
2. 02DetectContinuous monitoring identifies anomalous activity. Classify and prioritise incident by Impact × Urgency (Low / Medium / High). Notification to legal/regulatory bodies if required (e.g. GDPR 72-hour rule).
3. 03RespondActivate IR capability. Primary concern: containment — stop the incident spreading. Gather evidence for attribution. Implement scenario-based responses from IRP. Ongoing reporting to stakeholders.
4. 04RecoverMay begin at detection phase. Eradicate root cause (replace hardware, block IPs, rebuild from known-good images), then restore normal operations. Ends when pre-incident service level is restored.
5. 05Post-IncidentFinalise documentation, gather lessons learned, conduct root-cause analysis. Update IRP and controls to prevent recurrence.

Cloud forensics is highly specialised. The distributed, multitenant nature of cloud makes evidence collection, chain of custody, and jurisdictional issues significantly more complex than on-premises investigations.

1. 01CollectionGather evidence; use original physical media where possible. In cloud, physical collection is often impossible — use virtual snapshots or CSP-provided tooling. Leave powered-on systems on to preserve volatile data. Verify integrity with hashing.
2. 02ExaminationProcess and filter collected data to identify what is relevant. Always work from verified copies — never the original — to preserve evidence integrity.
3. 03AnalysisInterpret findings; identify who did what, when, and how. Must be convincing, admissible, and relevant. Attribution is harder in multitenant environments.
4. 04ReportingPresent findings clearly with a demonstrated chain of custody. Report must be understandable to non-technical audience (e.g. a court). Any gap in chain of custody weakens the evidence.

Audits may be financial, compliance, or security-focused. In cloud, SOC 2 Type II and ISO 27001 certifications are common audit outputs. Audit frameworks typically dictate deliverables and auditor qualifications.

PHASE 1: PLANNING — key tasks

1. 1aDefine objectivesCollaborative effort to determine systems/processes to be audited and standards to apply. Often begins many months in advance.
2. 1bGap analysis / readiness assessmentMock audit by internal personnel to identify issues before the formal audit.
3. 1cDefine deliverablesReport, data for leadership, action items. Many frameworks (SOC 2, FedRAMP) dictate the specific deliverables.
4. 1dIdentify auditors and qualificationsFrameworks specify internal vs. third-party, plus required credentials (e.g. CPA for SOC).
5. 1eDefine scope and restrictionsDocumented formally in the audit report so consumers can understand what was and wasn't covered.

PHASES 2–4: EXECUTION

1. 02Audit FieldworkExamine evidence, interview personnel, test controls. Findings captured as notes throughout.
2. 03Audit ReportingDraft report issued to allow organisation to challenge inaccuracies. Final report issued once agreed.
3. 04Audit Follow-UpAddress identified weaknesses. Auditors may retest fixed controls and issue an addendum. Consumers of the report will ask what was done to address findings.

Governed by the CMB (Configuration Management Board) or CCB (Change Control Board). Change types: low-risk (pre-authorised), normal (full process), emergency (expedited, documented after).

INITIAL BASELINE (one-time)

1. 01Full Asset InventoryDetermine what exists. May use BIA as an input.
2. 02Codify the BaselineFormal action with all CMB members. Negotiated via cost-benefit and risk analysis. Reflects organisation's risk appetite.
3. 03Secure Baseline BuildConstruct and store the approved baseline version for future reference.
4. 04Deploy to New AssetsApply baseline to each new asset acquired, per CM policy and CMB guidance.

ONGOING OPERATIONAL MODE

1. 01CMB MeetingsReview change and exception requests. CMB can authorise, disallow, or request additional analysis/funding before authorising.
2. 02CM TestingAuthorised changes tested in an isolated sandbox that mirrors production — never in production directly.
3. 03DeploymentModification made per approved plan. Reported to CMB upon completion.
4. 04DocumentationAll modifications reflected in the asset inventory and baseline. Asset disposal is also a modification and must be documented.

Vendor relationships in cloud carry inherent lock-in risk. Due diligence at selection and ongoing assessment during maintenance are both required. Relevant standard: ISO 27036 (information security for supplier relationships).

1. 01Vendor SelectionRFP or informal evaluation. Security contributes to requirements and evaluation. Assess vendor's own risk management programme, controls, and financial viability.
2. 02OnboardingVerify contract terms. Establish data transfer controls (encryption in transit and at rest). Set up incident notification procedures. Agree data ownership and deletion terms.
3. 03MaintenanceOngoing vendor assessments: site visits, review of independent audit reports (e.g. SOC 2 annually). Handle security incidents. A vendor that never reports incidents is a red flag.
4. 04OffboardingEnsure secure deletion of all confidential data. Orderly wind-down of the relationship. Lifecycle may then restart with a new vendor selection.

BCP keeps the business running during a disaster; DRP returns it to normal afterwards. They are separate plans but must be developed together with shared integration points. Both are activated by formal disaster declaration.

1. 01Conduct BIAIdentify critical processes and supporting systems. Determine RTO, RPO, and MTD requirements. Prioritise: critical → important → support processes. SSO and identity systems must be restored before dependent systems.
2. 02Prioritise RecoveryOrder systems by criticality. Document dependencies and the required restoration sequence. Only critical processes get priority — social/ancillary systems can wait.
3. 03Plan ContinuityIdentify failover capabilities (automated failovers, alternate sites, cloud DR). Understand CSP availability regions, replication, and backup options. Architect cloud apps to meet continuity requirements.
4. 04Document Plans and ProceduresBCP and DRP documents with step-by-step instructions for high-stress scenarios. Include critical asset inventory, disaster declaration criteria, escalation authority, contact lists, and evacuation procedures.
5. 05Test, Train, and MaintainExercises and drills. Update plans after tests, incidents, or infrastructure changes. Training is critical — key personnel must know their roles before an emergency.

STRIDE — THREAT TAXONOMY (Microsoft)

DREAD — QUANTITATIVE SCORING (Microsoft, largely deprecated)

PASTA — 7 STEPS (Process for Attack Simulation and Threat Analysis)

1. 01Define ObjectivesBusiness objectives, security and compliance requirements, BIA to identify high-priority systems.
2. 02Define Technical ScopeTechnical boundaries and all assets within them: hosts, apps, protocols, data assets.
3. 03Application DecompositionBreak complex apps into smaller components; define data flows and communications.
4. 04Threat AnalysisUse threat intelligence and logs to identify the most likely attack vectors.
5. 05Vulnerability AnalysisIdentify vulnerabilities and correlate to threats. Risk = threat + vulnerability.
6. 06Attack ModellingSimulate attacks using threat–vulnerability pairs to assess likelihood and impact.
7. 07Risk and Impact AnalysisUpdate BIA with findings. Prioritise risk treatment by criticality and operational impact.

ATASM — 4 STEPS (Architecture, Threats, Attack Surfaces, Mitigations)

1. 01ArchitectureAnalyse system architecture; enumerate technology components, functions, and assets requiring protection.
2. 02ThreatsList all possible threats, threat actors, goals, and methods (e.g. phishing for credentials to gain unauthorised access).
3. 03Attack SurfacesIdentify all exposed parts of the system. Remove surfaces already adequately secured by existing controls.
4. 04MitigationsApply new controls to remaining attack surfaces; use defence-in-depth as the implementation strategy.

Used to measure distance between current state and a target framework (e.g. ISO 27002, NIST CSF). Often performed before a formal audit as a readiness assessment. Results can drive risk prioritisation.

1. 01Establish Need and Gain Management SupportSecure buy-in and resourcing before committing to the analysis.
2. 02Define Scope, Objectives, and FrameworksSelect the reference framework (e.g. ISO 27002, NIST CSF) to compare against.
3. 03Identify Current StateEvaluate the area under review — research, interviews with employees, review of processes and controls.
4. 04Review Evidence and DocumentationVerify statements and data; substantiate findings with documentary evidence.
5. 05Identify GapsHighlight differences between the framework requirements and current reality. Each gap represents a risk to the organisation.
6. 06Prepare Report and Obtain Sign-OffDetail findings and get approval from appropriate leaders. Gaps should be prioritised by risk — address those that map to known risks first.