Run a POPIA-Aware AWS Tabletop

Run a POPIA-aware AWS incident-response tabletop for an ECS compromise.

Introduction

30 Second Summary

A security alert rarely arrives with every answer attached. Unclear ownership can turn incomplete evidence into a slow response.

In this project, you will build a reusable drill pack for a suspected compromised Amazon ECS task. You will run a tabletop exercise from an ambiguous Amazon GuardDuty signal to a POPIA-aware response for exposed location information.

What You'll Build

You read each fictional inject aloud as your team updates one decision log from uncertain detection through a defensible POPIA-aware recovery.

By the end of this project, you'll have:

  • A role-led scenario that assigns clear responsibilities for incident command, technical response, communications, plus Information Officer liaison.
  • An evidence matrix that links the GuardDuty finding to a Secrets Manager access event. It exposes missing Amazon S3 data events as an evidence gap.
  • A response runbook you can follow from evidence preservation through task isolation to a known-good replacement. A linked POPIA escalation checklist leads into a draft data-subject notice plus owned after-action improvements.
  • Secret Mission: Build an alternate scenario branch where Amazon S3 object-level evidence remains unavailable. The team must record an evidence-limited conclusion without inventing certainty.

Are there any prerequisites?

You need a Windows device. No AWS account, regulator submission, or legal expertise is required.

Before We Start

This step locks in the purpose and safety boundary of your tabletop before the scenario begins. Your drill stays local and costs nothing because it makes no AWS changes, API calls, cloud-resource changes, or regulator submissions.

Set Up the Local Drill Workspace

A tabletop exercise loses value when evidence, decisions, and references are scattered across different places. This step creates one local source of truth before the first incident inject arrives.

Microsoft Edge will hold three official reference pages. Windows Notepad will hold a facilitator pack and decision log on your Desktop.

In this step, get ready to:
  • Confirm Microsoft Edge and Windows Notepad are available.
  • Open three official incident-response references.
  • Create two blank tabletop templates inside aws-ir-tabletop.
Confirm your tools and open the references

The official references define the boundaries for later decisions. The AWS guidance covers simulations. The POPIA sources ground the security-compromise discussion.

  • Use Windows taskbar search to find Microsoft Edge.
  • Select Microsoft Edge from the search results.

You should see Microsoft Edge open to a browser window.

  • Use Windows taskbar search to find Windows Notepad.
  • Select Windows Notepad from the search results.

You should see Windows Notepad open to a blank document.

✔️ I can open both tools

Both tools launched successfully. Your local workspace is ready for the reference pages and text files.

ⓧ One or both tools are missing

Installing a missing app may trigger a device-approval request. If your organisation manages this Windows device, ask its support team to approve the installation.

  • Open the official Microsoft Edge download page in an available browser.
  • Install Microsoft Edge by following Microsoft’s Windows instructions.
  • Open the official Windows Notepad listing in an available browser.
  • Install Windows Notepad by following Microsoft’s instructions.
  • Repeat the Windows search check for Microsoft Edge.
  • Repeat the Windows search check for Windows Notepad.

Installation blocked?

A managed Windows device may prevent software installation without administrator approval. Help me work out how to access Microsoft Edge or Windows Notepad on my managed Windows device.

You should now have official AWS simulation guidance beside the POPIA Act. These pages establish the exercise format and the legal source used later.

You should see three Microsoft Edge tabs from official AWS, Department of Justice, and Information Regulator domains. Keep these tabs open for the later evidence and escalation decisions.

Why use a tabletop?

AWS describes tabletop exercises as discussion-based sessions for practising responsibilities, communication, and playbooks. That format lets your team test decisions without running scripts or changing an AWS environment.

Reference page not loading?

Confirm your device has an internet connection. A managed network may also block external documentation or PDF files.

Having trouble with one of the official pages? Help me identify why an official tabletop reference page is not loading.

Create the facilitator pack

The facilitator pack gives every exercise section a fixed home. Its blank headings create structure without introducing incident details from later steps.

  • Switch back to Windows Notepad from the availability check.
  • Start a new blank document using the Notepad file menu.

You should see an empty editing area ready for the facilitator template.

  • Copy the reusable section headings into the blank Notepad document:
Scenario

Roles

Injects

Containment

Recovery

After-Action Report

What does this template contain?

  • Scenario holds the fictional situation presented to participants.
  • Roles holds the exercise responsibilities.
  • Injects holds the progressive evidence updates.
  • Containment holds the ordered actions that limit harm.
  • Recovery holds the checks required before service restoration.
  • After-Action Report holds strengths, gaps, and owned improvements.
  • Start a new save for the current document using the Notepad file menu.
  • Choose your Desktop as the save location.

You should see your Desktop as the current location in the save window.

  • Create a folder named aws-ir-tabletop on the Desktop.
  • Enter the new aws-ir-tabletop folder.

The save location should now end with aws-ir-tabletop.

  • Name the document facilitator-pack.txt.
  • Save the document inside aws-ir-tabletop.

You should see facilitator-pack.txt in Notepad’s title area. The document should contain the six headings in the same order as the template.

File name looks wrong?

Check that the Notepad title shows facilitator-pack.txt exactly. Remove any repeated file extension before saving again.

Still seeing the wrong file name? Help me save my facilitator pack as a plain text file.

Create the decision log and verify the workspace

The decision log keeps each choice tied to its owner, rationale, and evidence. The final column makes missing telemetry visible instead of letting assumptions hide inside the discussion.

  • Start another blank document using the Notepad file menu.

You should see a new empty Notepad document beside the saved facilitator pack.

  • Copy the decision-log columns into the blank document:
Time | Inject | Decision | Owner | Rationale | Known Evidence | Evidence Gap

Why use these columns?

  • Time and Inject preserve the point in the scenario when a decision was made.
  • Decision and Owner make the chosen action accountable.
  • Rationale records why the team considered the decision defensible.
  • Known Evidence separates verified facts from the team’s interpretation.
  • Evidence Gap records what the available telemetry cannot establish.
  • Start a new save for the current document using the Notepad file menu.
  • Choose the existing Desktop folder named aws-ir-tabletop.

You should see facilitator-pack.txt inside the selected folder. This confirms you are saving both templates together.

  • Name the document decision-log.txt.
  • Save the document inside aws-ir-tabletop.

You should see decision-log.txt in Notepad’s title area. The single header row should remain blank underneath.

Columns missing or wrapped?

Compare the header with the template above. Every column must appear once in the stated order.

Need help correcting the decision log? Help me check the columns in my tabletop decision log.

Before you reopen the files, do you expect both blank templates to return exactly as saved? Hold that prediction while you test the workspace.

  • Close the facilitator-pack.txt tab in Windows Notepad.
  • Close the decision-log.txt tab in Windows Notepad.
  • Reopen facilitator-pack.txt from the Desktop folder named aws-ir-tabletop using the Notepad file menu.

You should see the six facilitator headings return in their original order. This proves the reusable pack was saved locally.

  • Reopen decision-log.txt from the same aws-ir-tabletop folder using the Notepad file menu.

You should see both filenames as Notepad tabs. facilitator-pack.txt contains all six headings. decision-log.txt contains the seven required columns with no decision rows yet.

✔️ Awesome, I've got everything!

Your three official reference pages are open in Microsoft Edge. Your two blank tabletop files are saved together inside aws-ir-tabletop.

ⓧ I'd like to double check the full code

  • Compare facilitator-pack.txt with this complete reference:
Scenario

Roles

Injects

Containment

Recovery

After-Action Report

What should match?

The file contains six headings in this exact order. The blank space beneath each heading is ready for later exercise content.

  • Compare decision-log.txt with this complete reference:
Time | Inject | Decision | Owner | Rationale | Known Evidence | Evidence Gap

What should match?

The file contains one header row with seven columns. No tabletop decisions appear below it yet.

That is your local source of truth ready. Next, you’ll assign the response roles and test the team against an ambiguous opening signal.

Trigger and Triage the Incident

Your local drill pack gives the tabletop exercise one source of truth. The next goal is to turn that blank structure into an active incident.

The first signal from GuardDuty Runtime Monitoring is intentionally ambiguous. You need clear ownership plus a defensible first decision before the scenario offers certainty.

In this step, get ready to:
  • Assign the incident-response responsibilities.
  • Present a fictional opening inject based on an ambiguous GuardDuty finding.
  • Record the first triage decision with its supporting evidence gaps.
Assign the response roles

Clear incident command keeps an urgent discussion from becoming a collection of unowned suggestions. Each role needs a defined decision area before Inject 1 begins.

Role responsibilities

  • Incident Commander: Owns the incident declaration plus response priorities.
  • Technical Lead: Owns evidence requests plus technical recommendations.
  • Communications or Information Officer Liaison: Owns stakeholder updates plus the Information Officer handoff.
  • Role flexibility: One person may hold more than one responsibility in a small team.
  • Switch back to facilitator-pack.txt in Windows Notepad.
  • Find the Roles heading.
  • Add the four role details from the callout beneath Roles.
  • Save facilitator-pack.txt.
  • Read the completed Roles section.

You should see a clear owner for command decisions. You should also see named responsibility areas for technical response plus communications.

Why use incident command?

An unstructured discussion makes urgent decisions easy to delay. Incident command gives each decision a clear owner while the team collaborates on the evidence.

A tabletop makes that ownership visible without touching a live environment. The exercise tests people plus process through discussion.

Write the ambiguous opening inject

A GuardDuty finding with Resource type set to ECSCluster indicates that an Amazon ECS task or a container inside a task may be compromised. That signal supports triage without establishing exactly what happened.

What belongs in Inject 1?

  • Inject label: Inject 1.
  • Finding description: A fictional simulated GuardDuty Runtime Monitoring finding.
  • Resource detail: Resource type is ECSCluster.
  • Interpretation: An ECS task or a container inside a task may be compromised.
  • Data label: Every account name is Fictional exercise data. Apply the same label to every task name. Apply it to every timestamp. Apply it to every identifier.
  • Exercise boundary: This is a simulation with no AWS changes. It creates no AWS spend.
  • Find the Injects heading in facilitator-pack.txt.
  • Add the six Inject 1 details from the callout beneath Injects.
  • Save facilitator-pack.txt.
  • Read the completed Inject 1 entry.

You should see an ambiguous simulated finding with an explicit fictional-data label. The exercise boundary should still confirm that no AWS environment changes occur.

Good progress. Your tabletop now has accountable responders plus a safe opening signal.

  • Check the visible text for real account names or real identifiers.
  • Replace any real information with Fictional exercise data.
Run the three-minute triage

A defensible triage record separates observed signals from assumptions. A working hypothesis directs the next evidence request without pretending the case is settled.

  • Read Inject 1 aloud.
  • Take three minutes to decide whether to declare an incident.
  • Choose an initial severity for the current evidence.
  • State one working hypothesis about the potentially compromised workload.
  • Name a fictional affected-service owner to contact.
  • Separate the known evidence from the assumptions in your triage discussion.
  • Choose the first evidence request that would test the working hypothesis.

Map the triage into the decision log

  • Time: Record the fictional exercise decision time.
  • Inject: Record Inject 1.
  • Decision: Record the incident-declaration decision. Include the initial severity.
  • Owner: Record the Incident Commander as the incident owner. Include the fictional service owner to contact.
  • Rationale: Record the working hypothesis. Label each unverified claim as an assumption.
  • Known Evidence: Record the simulated GuardDuty Runtime Monitoring finding. Include the ECSCluster resource detail.
  • Evidence Gap: Record the next evidence request.
  • Add one triage row to decision-log.txt using the mapping from the callout.
  • Save decision-log.txt.
  • Close facilitator-pack.txt in Windows Notepad.
  • Close decision-log.txt in Windows Notepad.
  • Reopen facilitator-pack.txt from the aws-ir-tabletop folder in Windows Notepad.
  • Reopen decision-log.txt from the aws-ir-tabletop folder in Windows Notepad.

Before you perform the final check, do you think the log shows a conclusion or a decision made under uncertainty?

  • Read Inject 1 aloud from the reopened facilitator pack.
  • Inspect the Inject 1 row in the reopened decision log.

You should see an incident owner plus an initial severity in the row. You should also see one working hypothesis plus the service owner to contact.

The evidence notes should distinguish facts from assumptions. The final field should name the next evidence request.

That is the first hard call made. Your team now has a defensible decision without claiming certainty the opening signal cannot provide.

Missing a triage field?

  • Add the initial severity to the Decision field if the row only records whether you declared an incident.
  • Move unverified claims into Rationale if they appear as facts. Label each one as an assumption.
  • Rewrite a vague Evidence Gap as a specific evidence request that can test the working hypothesis.

Still stuck? Help me check whether my Inject 1 triage row separates evidence, assumptions, and evidence gaps.

✔️ Awesome, I've got everything!

Your facilitator pack now contains the assigned roles plus the fictional opening inject. Your decision log captures the first evidence-aware triage decision.

ⓧ I'd like to double check the full code

  • Confirm Microsoft Edge remains open to the official AWS Well-Architected simulation guidance, the POPIA Act, plus the Information Regulator security-compromise fact sheet.
  • Confirm facilitator-pack.txt still contains Scenario, Roles, Injects, Containment, Recovery, plus After-Action Report.
  • Confirm the Roles section assigns Incident Commander, Technical Lead, plus Communications or Information Officer Liaison responsibilities.
  • Confirm the role section allows one person to hold multiple responsibilities.
  • Confirm Inject 1 describes a fictional simulated GuardDuty Runtime Monitoring finding with Resource type set to ECSCluster.
  • Confirm every account name, task name, timestamp, plus identifier is marked as fictional exercise data.
  • Confirm the facilitator pack says the exercise makes no AWS changes. It should also say the exercise creates no AWS spend.
  • Confirm decision-log.txt still contains Time, Inject, Decision, Owner, Rationale, Known Evidence, plus Evidence Gap.
  • Confirm the Inject 1 row records an incident owner, initial severity, working hypothesis, fictional service owner, known evidence, assumptions, plus the next evidence request.

Your incident now has owners, a safe opening inject, plus a documented first decision. Next, you will test that decision against additional evidence and a missing-telemetry gap.

Correlate Evidence and Identify the Logging Gap

Your opening tabletop exercise triage gave the incident an owner. It also captured the first evidence request.

The team now expects AWS evidence to settle whether data was touched. This step tests that expectation by separating what each signal supports from what remains unproven.

In this step, get ready to:
  • Add a second evidence inject that links the affected task role to secret retrieval.
  • Build an evidence matrix that separates support from proof.
  • Use the missing object record to identify the logging gap.
Add the second evidence inject

A simulated event in AWS CloudTrail adds a second signal. It links AWS Secrets Manager retrieval to the affected Amazon ECS task role soon after the Amazon GuardDuty Runtime Monitoring finding.

  • Switch back to facilitator-pack.txt in Windows Notepad.
  • Find the Injects heading.
  • Add Inject 2 beneath Inject 1 with a simulated CloudTrail GetSecretValue event under the affected ECS task role shortly after the GuardDuty finding.
  • Add that CloudTrail Event history has no Amazon S3 object-level record.
  • Read Inject 2 aloud to confirm both observations are present.
  • Mark Inject 2 as fictional exercise evidence.
  • Save facilitator-pack.txt.

Inject 2 now adds evidence of secret retrieval. It still leaves object access unresolved.

What does Inject 2 support?

The GetSecretValue event supports that the affected task role retrieved a secret shortly after the finding. It does not prove how the secret was used.

The absent object record is an observed state at this point. Your team still needs to determine what that absence can support.

Build the evidence matrix

An evidence matrix gives every signal clear limits. Each row records what the evidence supports before stating what it cannot prove.

  • Switch back to decision-log.txt in Windows Notepad.
  • Add an Evidence Matrix section with the columns Signal, What It Supports, What It Does Not Prove, Source, and Next Check.
  • Add a row for the GuardDuty ECSCluster finding that supports possible compromise of an ECS task or a container inside a task.
  • Read the GuardDuty row from left to right to confirm it does not claim that an S3 object was accessed.
  • Add a row for the CloudTrail GetSecretValue event that supports secret retrieval under the affected task role.
  • Read the Secrets Manager row from left to right to confirm it does not claim that an S3 object was read.
  • Add an initial row whose signal is the absent S3 GetObject record and whose source is CloudTrail Event history.

Before you interpret that final row, do you think the absence of a GetObject record proves that no object was read?

  • Ask the tabletop team whether the missing GetObject record supports a confident no-access conclusion.

The defensible answer is No. The missing record leaves the scope unresolved.

Why the missing record matters

Amazon S3 object-level operations such as GetObject are CloudTrail data events. CloudTrail data events are not logged by default.

An absent record can reflect missing coverage. It cannot establish that no object was read.

  • Complete the What It Supports cell by recording that CloudTrail Event history contains no matching S3 object-level record for the scenario.
  • Complete the What It Does Not Prove cell by recording that absence of a GetObject record does not prove no object was read.
  • Read those two cells aloud to confirm the matrix separates observation from conclusion.
  • Complete the Next Check cell by recording that the team must confirm whether S3 object-level data-event coverage was enabled.
  • Add an evidence-gap statement that records GetObject as a CloudTrail data event that is not logged by default.
  • Read the evidence-gap statement aloud to confirm it says missing telemetry does not prove no object was read.
  • Save decision-log.txt.

Your matrix now records the logging gap beside the affected evidence. Every later decision can carry that uncertainty forward.

Verify the evidence gap

A useful matrix blocks claims that exceed the available evidence. This check confirms your final row does exactly that.

  • Read Inject 2 aloud from facilitator-pack.txt.

Before you test the matrix, do you expect the absent record to support a confident no-access decision?

  • Test the matrix by asking aloud whether absence of a GetObject record proves that no object was read.

You should answer No. The matrix should identify missing S3 data-event coverage as the evidence gap.

Good work. Your drill pack now prevents missing telemetry from becoming false certainty.

✔️ My evidence pack matches

Your two files now preserve the original triage record. They also contain Inject 2 plus the completed evidence matrix.

ⓧ I'd like to double check the full pack

Use this checkpoint to compare the cumulative drill pack with the required state.

  • Confirm Microsoft Edge remains open to the official AWS Well-Architected simulation guidance.
  • Confirm Microsoft Edge remains open to the POPIA Act.
  • Confirm Microsoft Edge remains open to the Information Regulator security-compromise fact sheet.
  • Confirm facilitator-pack.txt retains the Scenario, Roles, Injects, Containment, Recovery, and After-Action Report headings.
  • Confirm facilitator-pack.txt retains the Incident Commander responsibility.
  • Confirm facilitator-pack.txt retains the Technical Lead responsibility.
  • Confirm facilitator-pack.txt retains the Communications or Information Officer Liaison responsibility.
  • Confirm Inject 1 retains the fictional GuardDuty Runtime Monitoring finding with Resource type set to ECSCluster.
  • Confirm Inject 2 records the simulated CloudTrail GetSecretValue event under the affected ECS task role shortly after the GuardDuty finding.
  • Confirm Inject 2 records that CloudTrail Event history has no S3 object-level record.
  • Confirm the facilitator pack still states that the exercise makes no AWS changes and incurs no AWS spend.
  • Confirm decision-log.txt retains the completed Inject 1 triage entry.
  • Confirm the evidence matrix uses the columns Signal, What It Supports, What It Does Not Prove, Source, and Next Check.
  • Confirm the matrix covers the GuardDuty ECSCluster finding.
  • Confirm the matrix covers the CloudTrail GetSecretValue event under the affected task role.
  • Confirm the matrix covers the absent S3 GetObject record.
  • Confirm the matrix states that S3 GetObject is a CloudTrail data event.
  • Confirm the matrix states that CloudTrail data events are not logged by default.
  • Confirm the matrix states that absence of a GetObject record does not prove no object was read.

Your evidence matrix now protects the team from false certainty. Next, a stronger inject will force a POPIA escalation decision.

Make the POPIA Escalation Decision

Your evidence matrix kept the missing Amazon S3 object record from becoming false reassurance. It now gives you a disciplined baseline for the next inject.

Inject 3 links a read of identifiable location information to the compromised Amazon ECS task. This crosses the scenario from suspected compromise into reasonable grounds for a POPIA escalation decision.

Technical response must now proceed alongside regulatory handling. Your team needs a named escalation owner before the scenario can move into containment.

In this step, get ready to:
  • Add fictional Inject 3 with the retained-trail evidence.
  • Complete the POPIA section 22 escalation checklist.
  • Draft the data-subject notice.
Add the breach-confirmation inject

Inject 3 fills the evidence gap from the previous step. A retained CloudTrail trail now connects the affected task role to an object read involving identifiable customer location information.

What Does Inject 3 Establish?

  • A simulated retained-trail GetObject data event records a read by the affected role.
  • The object is an export containing identifiable customer location information.
  • The role session is linked to the compromised task.
  • The material is fictional exercise evidence.
  • No real customer record appears in the facilitator pack.
  • Switch back to facilitator-pack.txt in Windows Notepad.
  • Find the Injects heading.
  • Add a new Inject 3 entry beneath Inject 2 using every fact above.
  • Read Inject 3 aloud to confirm its evidence chain.

You should hear a clear path from the affected role to the export. The role session should finish that path by linking the read to the compromised task.

That is the scenario's turning point. Your facilitator pack now contains evidence that changes the response threshold.

Apply the POPIA section 22 checklist

Reasonable grounds are the threshold for this decision. Your checklist must connect that threshold to the evidence before assigning the regulatory handoff.

What Activates POPIA Section 22?

The trigger exists where there are reasonable grounds to believe that personal information was accessed or acquired by an unauthorised person.

Notification must occur as soon as reasonably possible after discovery. Legitimate law-enforcement needs may affect the timing.

Measures needed to determine scope may also affect the timing. Work needed to restore system integrity may affect it too.

The Information Regulator says the Information Officer or Deputy Information Officer should report the security compromise to the Regulator plus affected data subjects.

  • Switch back to the POPIA Act page in Microsoft Edge.
  • Use section 22 to confirm the escalation trigger.
  • Use section 22 to confirm the notification timing requirement.
  • Switch back to the Information Regulator security-compromise fact sheet.
  • Confirm which organisational role should handle the report.

Your reference check should identify reasonable grounds as the trigger. It should identify the Information Officer or Deputy Information Officer as the reporting role.

What Belongs in the Checklist?

  • A decision on whether reasonable grounds exist.
  • The Inject 3 evidence supporting that decision.
  • The Information Officer or Deputy Information Officer handoff.
  • The time when the escalation decision was made.
  • The reason for any delay.
  • A boundary note stating that a real organisation requires its own legal advice.
  • A boundary note stating that a real report must use the Information Regulator mandatory eServices process.
  • Add a POPIA Section 22 Checklist beneath Inject 3 in facilitator-pack.txt.
  • Complete the checklist using every field above.
  • Read the completed checklist aloud.

You should hear an evidence-based trigger decision with a named handoff owner. You should also hear a decision time plus an explanation for any delay.

  • Switch back to decision-log.txt in Windows Notepad.
  • Add one Inject 3 decision entry using the existing columns.
  • Record No delay if the exercise decision was made immediately.
  • Read across the completed entry to check that every decision has an owner.

The decision log should now connect the retained-trail evidence to the escalation decision. Its timestamp makes the timing reviewable after the exercise.

Draft the data-subject notice

This notice stays inside your local exercise. No message leaves your device.

A useful draft gives affected people enough information to take protective measures. Each statement must stay within the facts established by the exercise.

What Must the Notice Cover?

  • What happened.
  • When it happened.
  • The possible consequences.
  • The measures already taken or planned.
  • The protective actions recommended to affected people.
  • The identity of the unauthorised person if known.
  • Add a Draft Data-Subject Notice section beneath the Inject 3 decision entry in decision-log.txt.
  • Draft the notice using every field above.
  • State that the unauthorised person's identity is unknown if the exercise evidence does not establish it.
  • Read the completed notice aloud from the perspective of an affected person.

The notice should explain the incident without claiming facts the exercise has not established. It should give the reader a concrete protective recommendation.

Before you perform the final review, do you expect every escalation decision to trace back to Inject 3?

  • Review the POPIA section 22 checklist against the Inject 3 facts.
  • Review the Information Officer or Deputy Information Officer handoff.
  • Review the recorded decision time.
  • Review any stated reason for delay.
  • Review the draft notice against its six required fields.
  • Confirm the exercise still states that it made no AWS changes.
  • Confirm the exercise still states that it incurred no AWS spend.

Every required field should now be present. Any unknown detail should be labelled as unknown instead of being inferred.

That completes the escalation handoff. Your pack now ties regulatory decisions to evidence with an owner plus a reviewable timestamp.

Missing a Decision or Notice Field?

  • Compare the checklist with the Inject 3 facts to find any unsupported conclusion.
  • Check that the handoff names the Information Officer or Deputy Information Officer role.
  • Mark the unauthorised person's identity as unknown when the exercise evidence does not establish it.

Still stuck? Help me review my POPIA section 22 checklist and draft data-subject notice for missing fields or unsupported conclusions.

✔️ My escalation pack is complete

Your facilitator pack contains fictional Inject 3 plus the POPIA section 22 checklist. Your decision log contains the escalation decision plus the draft data-subject notice.

ⓧ I'd like to double check the files

Confirm that facilitator-pack.txt contains all of these items:

  • The existing Scenario, Roles, Injects, Containment, Recovery, plus After-Action Report headings.
  • The existing Incident Commander role.
  • The existing Technical Lead role.
  • The existing Communications or Information Officer Liaison role.
  • The existing fictional Injects 1 plus 2.
  • Fictional Inject 3 with the retained-trail GetObject evidence.
  • The link between the affected role session plus the compromised task.
  • The statement that Inject 3 is fictional exercise evidence.
  • The POPIA section 22 checklist.
  • The legal-advice boundary for a real organisation.
  • The mandatory eServices boundary for a real report.
  • The existing zero-spend boundary with no AWS changes.

Confirm that decision-log.txt contains all of these items:

  • The existing Inject 1 triage entry.
  • The existing evidence matrix.
  • The existing statement that missing S3 data-event telemetry does not prove no access.
  • The Inject 3 retained-trail evidence.
  • The reasonable-grounds decision.
  • The Information Officer or Deputy Information Officer handoff.
  • The escalation decision time.
  • The reason for any delay.
  • A draft notice describing what happened.
  • A draft notice stating when it happened.
  • A draft notice describing possible consequences.
  • A draft notice describing measures taken or planned.
  • A draft notice recommending protective actions.
  • A draft notice identifying the unauthorised person if known.

Your escalation decision now has evidence, ownership, timing, plus a practice notice. Next up, you will turn those decisions into a safe containment order with observable recovery checks.

Contain, Recover, and Close the Drill

Your earlier work linked fictional object access to the compromised task. It also established the POPIA handoff.

A compromise declaration only starts the response. The response now needs ordered containment that protects evidence before service changes.

This step creates a known-good recovery path. It closes the drill with owned improvements.

In this step, get ready to:
  • Write an ordered containment plan with evidence-based decision fields.
  • Build a known-good recovery sequence from vulnerability remediation through service restoration.
  • Complete the After-Action Report with assigned ownership plus target dates.
Write the containment order

Containment for a potentially compromised Amazon ECS task needs a deliberate order. The sequence starts by preserving evidence before the affected task is isolated.

Use one decision record

  • The Owner field assigns a role with authority to perform the action.
  • The Evidence Prerequisite field names the information required before the action proceeds.
  • The Expected Outcome field states the intended result.
  • The Rollback Consideration field records a safe reversal. It can also state why reversal would be unsafe.
  • The Observable Recovery Check field states what the team can inspect to confirm the result.

Containment order

  • First: Preserve relevant timestamps and identifiers.
  • Second: Identify the affected ECS cluster and task.
  • Third: Deny all ingress and egress traffic to the affected task.
  • Fourth: Decide whether the suspected secret must be rotated or revoked.
  • Return to facilitator-pack.txt in the aws-ir-tabletop workspace using Windows Notepad from earlier.
  • Find the Containment heading.
  • Add the four actions from the Containment order callout in the same order.
  • Complete every action with all five decision fields.
  • Read the completed Containment section aloud from evidence preservation through the secret decision.

You should hear a sequence that captures evidence before isolation. The secret decision should depend on the evidence recorded for the affected task role.

  • Return to decision-log.txt from earlier.
  • Add one row for each containment decision.
  • Complete the existing decision-log fields for every new row.
  • Review each row for an owner, rationale, known evidence, and evidence gap.

You should be able to connect every containment decision to the fictional evidence already recorded. Any unresolved telemetry question should remain visible as an evidence gap.

Plan the recovery order

A compromised task cannot provide the baseline for a trusted return to service. The recovery order fixes the vulnerability before a known-good replacement takes over.

Recovery order

  • First: Identify and fix the vulnerability.
  • Second: Start a known-good replacement task.
  • Third: Stop the vulnerable task after the evidence-preservation decision.
  • Fourth: Validate expected application behaviour plus authorised data access.
  • Fifth: Approve service restoration.
  • Return to facilitator-pack.txt from earlier.
  • Find the Recovery heading.
  • Add the five actions from the Recovery order callout in the same order.
  • Complete every recovery action with the same five decision fields.
  • Read the completed Recovery section aloud from vulnerability remediation through restoration approval.

You should hear the replacement task start before the vulnerable task stops. Restoration should follow observable checks of application behaviour plus authorised data access.

  • Return to decision-log.txt from earlier.
  • Add one row for each remediation, recovery, and service-restoration decision.
  • Complete the existing decision-log fields for every new row.
  • Review the new rows for a traceable link to the facilitator runbook.

The decision log should now explain why each recovery action proceeds. It should also preserve any evidence limitation that remains unresolved.

Close the drill with owned improvements

An After-Action Report turns exercise observations into accountable improvements. A gap becomes useful when one owner receives a corrective action with a target date.

After-Action Report checklist

  • Strengths name the parts of the response that supported timely decisions.
  • Gaps include the Amazon S3 data-event visibility gap plus the POPIA handoff.
  • Corrective actions state the change required for each gap.
  • Owners assign one accountable role to every corrective action.
  • Target dates define when each corrective action should be completed.
  • The exercise boundary confirms that no AWS changes were made. It also confirms that no AWS spend was incurred.
  • Return to facilitator-pack.txt from earlier.
  • Find the After-Action Report heading.
  • Complete the report using every requirement in the After-Action Report checklist callout.
  • Review every corrective action for one owner plus one target date.

You should see a clear path from each exercise gap to a measurable improvement. The report should preserve the zero-spend design boundary.

  • Save facilitator-pack.txt with Ctrl+S.
  • Return to decision-log.txt from earlier.
  • Save decision-log.txt with Ctrl+S.

Before you read the full runbook, predict whether every action has enough evidence to proceed safely.

  • Read the runbook aloud from the Inject 1 detection through approved service restoration.
  • Confirm each runbook action names an owner.
  • Confirm each runbook action states an evidence prerequisite.
  • Confirm each runbook action includes an expected outcome.
  • Confirm each runbook action includes a rollback consideration.
  • Confirm each runbook action includes an observable recovery check.
  • Confirm the decision log covers containment, remediation, recovery, and service restoration.
  • Confirm the After-Action Report pairs every corrective action with an owner plus a target date.

You should be able to trace the incident from Inject 1 through restoration without finding an unowned action or unsupported decision. You should also see every improvement paired with one owner plus one target date.

Strong finish. Your fictional tabletop now closes with controlled recovery plus measurable follow-through.

✔️ My drill pack is complete

Your facilitator pack now carries the full response order. Your decision log traces each decision to its evidence.

ⓧ I'd like to double check the full pack

  • Confirm Microsoft Edge remains open to the official AWS Well-Architected simulation guidance, the POPIA Act, and the Information Regulator security-compromise fact sheet.
  • Confirm decision-log.txt retains the initial triage, evidence matrix, Inject 3 escalation decision, Information Officer handoff, decision time, delay rationale if applicable, and draft data-subject notice.
  • Confirm decision-log.txt records the new containment, remediation, recovery, and service-restoration decisions with owners, rationale, known evidence, and evidence gaps.
  • Confirm facilitator-pack.txt retains the six original headings, three assigned roles, and three fictional injects.
  • Confirm the injects still include the GuardDuty Runtime Monitoring finding, the CloudTrail GetSecretValue event for Secrets Manager, and the retained-trail GetObject evidence.
  • Confirm Containment follows the four-action order from evidence preservation through the secret decision.
  • Confirm Recovery follows the five-action order from vulnerability remediation through approved restoration.
  • Confirm every runbook action has the five decision fields. Confirm the After-Action Report includes strengths, gaps, corrective actions, owners, target dates, the S3 data-event visibility gap, the POPIA handoff, and the zero-spend exercise boundary.

That closes the response loop. Your drill pack can now guide a team from ambiguous detection to controlled recovery.

Secret mission

Build the No-Data-Event Branch

Add an alternate branch where S3 object-level evidence remains unavailable after Inject 2. Your team must separate facts from assumptions before making an evidence-limited escalation decision.

Clean Up Your Resources

Clean Up Your Resources

Your drill pack is entirely local, so keeping it creates no AWS resources or ongoing cloud costs. Decide whether to keep it ready for another session, archive it until your team is available, or remove it completely.

Resources you used:

  • Local folder aws-ir-tabletop containing facilitator-pack.txt and decision-log.txt. The files include the primary incident path, alternate no-data-event branch, escalation materials, recovery runbook, and After-Action Report.

Keep everything running

No action is needed. Choose this option if your team plans to rerun or refine the tabletop.

  • Retain the aws-ir-tabletop folder in its current local location.
  • Replace every fictional identifier before each future exercise session.
  • Keep both scenario branches so facilitators can choose between confirmed access and evidence-limited escalation.

Pause - I'll come back to this later

This option stores the exercise until participants or an Information Officer representative are available. Your completed files remain available without any cloud cost.

  • Save facilitator-pack.txt in Windows Notepad.
  • Save decision-log.txt in Windows Notepad.
  • Close both tabletop documents.
  • Close the official reference tabs in Microsoft Edge.
  • Move the aws-ir-tabletop folder to your local archive location.
  • Confirm the archived folder still contains facilitator-pack.txt and decision-log.txt.

Delete - I don't want to use this again

Remove the local drill pack if you do not plan to reuse it. The project made no AWS changes or regulator submissions, so the folder is the complete cleanup target.

  • Copy the aws-ir-tabletop folder to a safe location first if you may need the exercise later.
  • Close facilitator-pack.txt in Windows Notepad.
  • Close decision-log.txt in Windows Notepad.
  • Use File Explorer to locate the aws-ir-tabletop folder in the same local location you chose in Step 1.
  • Delete the aws-ir-tabletop folder from your device.
  • Confirm the original location no longer contains the aws-ir-tabletop folder.

Nice Work!

Nice Work!

You made it! Your reusable incident-response tabletop now guides a fictional Amazon ECS compromise from an ambiguous GuardDuty signal through evidence-aware containment to a POPIA response.

You've learned how to:

  • Assigned incident command roles for a fictional GuardDuty Runtime Monitoring finding. Recorded a defensible first triage decision in decision-log.txt.
  • Correlated a CloudTrail event for the Secrets Manager GetSecretValue operation with the affected task role. Identified missing Amazon S3 object data events as an evidence gap.
  • Applied POPIA section 22 to document the escalation trigger plus the Information Officer handoff. Produced an owned runbook that moves from evidence preservation through known-good recovery to measurable after-action improvements.
  • Completed the optional Secret Mission by building an alternate no-data-event branch for unavailable S3 object-level evidence. The branch separates facts from assumptions before recording a justified action under uncertainty.

Ready to quiz yourself?