CraveCart's new IT Security Manager wants a single document that captures every known risk facing the company: which assets are at stake, what threats and vulnerabilities create that risk, and what's already being done about it. This document is called a risk register, and it's the foundation every other decision in Unit 6 builds on.

For each risk, the team rates likelihood (how probable is this?) and impact (how bad would it be?) to arrive at a qualitative risk rating of Low, Medium, or High. Existing controls are classified as preventive (stopping an attack before it happens), detective (identifying an attack in progress or after the fact), or corrective (restoring systems afterward) — and even with strong controls in place, some residual risk always remains. Layering all three control types together across the organization is what defense in depth really means in practice.

With the risk register in hand, CraveCart's security team steps back to look at the bigger picture: the company's overall security architecture — how physical, network, device, application, and data controls fit together as layered security. The goal is to find every place an attacker could get in, collectively called the attack surface, and reduce it through hardening before it leads to a compromise.

The review below reflects CraveCart's actual security posture heading into this unit. Most layers look solid thanks to work done in earlier units — but one control gap stands out, and it's about to matter a lot. Once gaps are identified, they get written into a remediation plan: what to fix, in what order, and how much business impact each unfixed gap could cause.

The control gap identified in Case 6B just became a real problem. CraveCart's security team is formally investigating the after-hours admin login and mass data export you may remember from earlier this course. What started as a suspicious audit log entry is now a full investigation, and it starts with collecting digital evidence properly.

Every piece of evidence collected must be logged with a documented chain of custody — who collected it, when, and where it's stored — so that it holds up to scrutiny later. While evidence is gathered, the response team is simultaneously working through containment (stopping the damage from spreading), eradication (removing whatever gave the attacker access), and recovery (getting systems back to normal). Once the dust settles, a post-incident review will capture lessons learned so this doesn't happen again.

With evidence collected, the investigation team's next job is correlation — lining up artifacts from several different log sources (email security, web proxy, and the admin audit log) into a single timeline to see how the attack actually unfolded. A single log entry rarely tells the whole story; it's the pattern across sources that reveals the truth.

Once the timeline is built, the team can determine the root cause — the real reason this happened, not just the moment it was noticed — and the scope of what was affected. That, in turn, shapes the containment strategy going forward. Look closely at the domain name in the timeline below: it may be familiar.

With the root cause identified, CraveCart's incident response plays out through its full, formal set of phases. Having a documented incident response plan already in place — built during preparation, long before this breach ever happened — is exactly why CraveCart could move quickly once identification occurred.

The phase tracker below shows where things stand. Notice that recovery isn't finished, and the after-action review — the step that captures lessons learned and strengthens the organization's resilience against a repeat attack — hasn't started yet. Until MFA rolls out fully, CraveCart is also using a temporary compensating control to reduce risk without disrupting business continuity for legitimate admin work.

With the incident closed out, CraveCart's leadership wants an honest answer to one question: is the company's overall security posture actually better now, or did the team just patch one hole? To answer that, the security team runs a gap analysis, comparing each security domain against a baseline — the level of protection the company should have to meet its own standards and any compliance requirements.

This kind of review is also an exercise in threat modeling: thinking ahead about what an attacker might try next, not just reacting to what already happened. For every gap found, the team must choose a risk treatment — fix it, accept it, or reduce it another way — and decide whether continuous monitoring needs to expand to catch the next attempt sooner.

CraveCart's leadership team — the stakeholders who ultimately approve spending — has asked the security team for one final deliverable: a prioritized security investment plan that closes the remaining gaps from Case 6F. Every proposed control below has a control objective it's meant to achieve, but none of them are free, and CraveCart doesn't have unlimited budget.

This is where a cost-benefit analysis earns its place: comparing what each control costs against its control effectiveness at reducing risk. Leadership has also set a risk appetite for the company — how much risk they're willing to tolerate — which means not every gap needs an expensive fix. Some risk can be addressed through risk acceptance (deciding to live with it) or risk transfer (like insurance), rather than direct investment. Whatever you recommend, it needs to be an evidence-based decision with clear justification, and it needs to work within CraveCart's real business requirements — this is your final mitigation strategy for the unit, built on defense in depth.