{"course":{"slug":"cloud-and-shipping","title":"Shipping It","url":"https://addaly.com/learn/cloud-and-shipping","level":"intermediate","track":"build"},"lesson":{"slug":"the-day-you-are-breached","title":"The first day of a security incident","url":"https://addaly.com/learn/cloud-and-shipping/the-day-you-are-breached","position":65,"of":74,"minutes":10,"answer":"In a security incident, preserve evidence before you clean anything, contain narrowly and rotate credentials, establish scope from logs rather than assumptions.","keyIdea":"In a security incident, preserve evidence before you clean anything, contain narrowly and rotate credentials, establish scope from logs rather than assumptions, and find out which notification clock applies to you before the day you need to know."},"body":{"format":"markdown","text":"## It does not look like the films\n\nA security incident usually starts as something small and confusing. A user says their account posted something they did not write. A cloud bill has an unfamiliar region on it. A support agent notices two accounts sharing one email. A researcher emails you a screenshot.\n\nThe outage runbook from earlier in this course does not fit, because the priorities are different in one specific way: **you must preserve evidence while you stop the damage**, and the instinct to \"clean it up\" destroys the information you will need for every decision afterwards.\n\n## The first hour\n\n1. **Write down the time and what you saw.** Start a document. Timestamp everything from here.\n2. **Preserve before you change.** Snapshot the machine, export the relevant logs to somewhere the incident cannot reach, and take a copy of the affected database. Do not rebuild the server yet. Once logs roll over, often in days, the answer to \"how did they get in\" is gone permanently.\n3. **Contain, narrowly first.** Revoke the compromised credential, disable the affected account, block the specific access path. Wholesale shutdown is available and expensive; use it when narrow containment is not working.\n4. **Rotate credentials that could plausibly be exposed**, in the order the earlier rotation lesson gave: new key, deploy, watch, disable.\n5. **Get a second person involved.** Not for expertise; for the decisions. Alone at 2am is when people delete things they needed.\n\nWhat not to do: log into the compromised machine and start poking, which contaminates timestamps; announce a cause in the first hour; or promise users that nothing was taken before you know.\n\n## Establish scope with evidence, not with hope\n\nThe question everybody wants answered is \"what did they get\". Answer it from logs, not from reasoning about what should have been possible.\n\n- Which credential was used, and what could that credential reach?\n- What queries or requests were made with it, and how much data left?\n- When did it start? The gap between the first sign and your detection is the number that matters most, and it is usually longer than people expect.\n- Is the access still live? Assume yes until you have positive evidence otherwise.\n\nIf you cannot establish scope, say so. \"We do not yet know\" is a legitimate finding and a far better public statement than a confident claim you later withdraw.\n\n## The obligations, in shape rather than in detail\n\nThis is where the honest answer is that the rules differ by jurisdiction and by the kind of data, and this course cannot tell you what applies to you.\n\nThe shape, roughly, in several regimes: if personal data is exposed, a regulator may have to be told within a short window: 72 hours from becoming aware is the well-known figure under the European regime, and other countries have their own periods, some shorter for particular sectors. Affected individuals often have to be told directly when the risk to them is high. Some sectors (health, finance, children's data) carry stricter duties. Contracts with business customers frequently impose faster notification than the law does, and people forget to read those.\n\nWhat follows for you, practically:\n\n- Find out **before an incident** which regimes you are under and what the clock is. Write it in the runbook with the actual deadline.\n- Keep a record of when you became aware, because the clock starts there and you will be asked.\n- If personal data of real people may be exposed, take advice from somebody qualified in your jurisdiction. Nothing here is legal advice, and this is one of the few places in this course where the stakes justify professional help.\n\n## Telling people, without making it worse\n\nWhen you notify, say: what happened, what data was involved, what it means for the reader, what you have done, what they should do, and when you will update again. Plain language, no minimising verbs, no \"sophisticated attack\" unless it was.\n\nThe reputational damage in published breach cases is rarely from the breach itself. It comes from the delay, the initial denial, or the phrase that turns out to be untrue. A short, early, accurate notice that says \"we do not yet know the full scope\" ages far better than a confident one that ages badly.\n\nIf passwords were involved, force a reset and end all sessions: the session lesson's revocation design is what makes that possible in minutes rather than days.\n\n## Not every incident is a breach\n\nKeep the categories separate, because they need different responses and different words:\n\n- **Credential stuffing**: attackers using passwords leaked from another service. Your system was not breached; individual accounts were. Say that precisely, help the affected users, and add the defences from the sessions lesson.\n- **A vulnerability report with no evidence of exploitation.** Fix it, thank the reporter, and check your logs for use before deciding whether anybody needs to be told.\n- **An internal mistake**: a public bucket, an over-broad query in an export. Still a data exposure, still possibly notifiable, and the containment steps are the same.\n\n## Afterwards\n\nRun the postmortem as usual, with two additions: the detection gap in hours, and an honest account of what evidence you did not have and now will. Most security post-incident actions are unglamorous: turn on logging you did not have, remove a credential that should not have existed, restrict a permission that was broader than the job needed. Those are the ones that make the next one smaller."},"check":{"question":"You discover an attacker has been using a leaked API key. The instinct is to rebuild the compromised machine immediately from a clean image. Why is that a poor first move?","options":[{"text":"Rebuilding does not revoke the key, so access continues","correct":false,"tempting":"True and important, but it argues for also revoking, not against preserving; a team could rebuild and revoke together and still have made the mistake."},{"text":"The clean image may contain the same vulnerability, so the attacker returns","correct":false,"tempting":"Plausible if the entry point was a code flaw, but here the entry was a leaked credential, and it still would not be the primary objection."},{"text":"It destroys the logs and system state needed to establish how they got in and what they reached","correct":true},{"text":"It causes downtime that must be reported to the regulator","correct":false,"tempting":"Confuses availability with data protection; notification duties attach to exposure of personal data, not to a maintenance outage."}]},"prev":{"slug":"the-admin-surface","title":"The tools that can do anything","url":"https://addaly.com/learn/cloud-and-shipping/the-admin-surface"},"next":{"slug":"when-somebody-reports-your-users","title":"The email about one of your users","url":"https://addaly.com/learn/cloud-and-shipping/when-somebody-reports-your-users"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The first day of a security incident', in Shipping It. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/cloud-and-shipping/the-day-you-are-breached (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The first day of a security incident","courseTitle":"Shipping It","module":{"index":7,"slug":"security-after-the-short-list","title":"Security after the short list"},"answer":null,"keyIdea":"In a security incident, preserve evidence before you clean anything, contain narrowly and rotate credentials, establish scope from logs rather than assumptions, and find out which notification clock applies to you before the day you need to know.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"it-does-not-look-like-the-films","runs":[{"text":"It does not look like the films"}]},{"t":"p","runs":[{"text":"A security incident usually starts as something small and confusing. A user says their account posted something they did not write. A cloud bill has an unfamiliar region on it. A support agent notices two accounts sharing one email. A researcher emails you a screenshot."}]},{"t":"p","runs":[{"text":"The outage runbook from earlier in this course does not fit, because the priorities are different in one specific way: "},{"text":"you must preserve evidence while you stop the damage","b":true},{"text":", and the instinct to “clean it up” destroys the information you will need for every decision afterwards."}]},{"t":"h2","id":"the-first-hour","runs":[{"text":"The first hour"}]},{"t":"ol","start":1,"items":[[{"text":"Write down the time and what you saw.","b":true},{"text":" Start a document. Timestamp everything from here."}],[{"text":"Preserve before you change.","b":true},{"text":" Snapshot the machine, export the relevant logs to somewhere the incident cannot reach, and take a copy of the affected database. Do not rebuild the server yet. Once logs roll over, often in days, the answer to “how did they get in” is gone permanently."}],[{"text":"Contain, narrowly first.","b":true},{"text":" Revoke the compromised credential, disable the affected account, block the specific access path. Wholesale shutdown is available and expensive; use it when narrow containment is not working."}],[{"text":"Rotate credentials that could plausibly be exposed","b":true},{"text":", in the order the earlier rotation lesson gave: new key, deploy, watch, disable."}],[{"text":"Get a second person involved.","b":true},{"text":" Not for expertise; for the decisions. Alone at 2am is when people delete things they needed."}]]},{"t":"p","runs":[{"text":"What not to do: log into the compromised machine and start poking, which contaminates timestamps; announce a cause in the first hour; or promise users that nothing was taken before you know."}]},{"t":"h2","id":"establish-scope-with-evidence-not-with-hope","runs":[{"text":"Establish scope with evidence, not with hope"}]},{"t":"p","runs":[{"text":"The question everybody wants answered is “what did they get”. Answer it from logs, not from reasoning about what should have been possible."}]},{"t":"ul","items":[[{"text":"Which credential was used, and what could that credential reach?"}],[{"text":"What queries or requests were made with it, and how much data left?"}],[{"text":"When did it start? The gap between the first sign and your detection is the number that matters most, and it is usually longer than people expect."}],[{"text":"Is the access still live? Assume yes until you have positive evidence otherwise."}]]},{"t":"p","runs":[{"text":"If you cannot establish scope, say so. “We do not yet know” is a legitimate finding and a far better public statement than a confident claim you later withdraw."}]},{"t":"h2","id":"the-obligations-in-shape-rather-than-in-detail","runs":[{"text":"The obligations, in shape rather than in detail"}]},{"t":"p","runs":[{"text":"This is where the honest answer is that the rules differ by jurisdiction and by the kind of data, and this course cannot tell you what applies to you."}]},{"t":"p","runs":[{"text":"The shape, roughly, in several regimes: if personal data is exposed, a regulator may have to be told within a short window: 72 hours from becoming aware is the well-known figure under the European regime, and other countries have their own periods, some shorter for particular sectors. Affected individuals often have to be told directly when the risk to them is high. Some sectors (health, finance, children’s data) carry stricter duties. Contracts with business customers frequently impose faster notification than the law does, and people forget to read those."}]},{"t":"p","runs":[{"text":"What follows for you, practically:"}]},{"t":"ul","items":[[{"text":"Find out "},{"text":"before an incident","b":true},{"text":" which regimes you are under and what the clock is. Write it in the runbook with the actual deadline."}],[{"text":"Keep a record of when you became aware, because the clock starts there and you will be asked."}],[{"text":"If personal data of real people may be exposed, take advice from somebody qualified in your jurisdiction. Nothing here is legal advice, and this is one of the few places in this course where the stakes justify professional help."}]]},{"t":"h2","id":"telling-people-without-making-it-worse","runs":[{"text":"Telling people, without making it worse"}]},{"t":"p","runs":[{"text":"When you notify, say: what happened, what data was involved, what it means for the reader, what you have done, what they should do, and when you will update again. Plain language, no minimising verbs, no “sophisticated attack” unless it was."}]},{"t":"p","runs":[{"text":"The reputational damage in published breach cases is rarely from the breach itself. It comes from the delay, the initial denial, or the phrase that turns out to be untrue. A short, early, accurate notice that says “we do not yet know the full scope” ages far better than a confident one that ages badly."}]},{"t":"p","runs":[{"text":"If passwords were involved, force a reset and end all sessions: the session lesson’s revocation design is what makes that possible in minutes rather than days."}]},{"t":"h2","id":"not-every-incident-is-a-breach","runs":[{"text":"Not every incident is a breach"}]},{"t":"p","runs":[{"text":"Keep the categories separate, because they need different responses and different words:"}]},{"t":"ul","items":[[{"text":"Credential stuffing","b":true},{"text":": attackers using passwords leaked from another service. Your system was not breached; individual accounts were. Say that precisely, help the affected users, and add the defences from the sessions lesson."}],[{"text":"A vulnerability report with no evidence of exploitation.","b":true},{"text":" Fix it, thank the reporter, and check your logs for use before deciding whether anybody needs to be told."}],[{"text":"An internal mistake","b":true},{"text":": a public bucket, an over-broad query in an export. Still a data exposure, still possibly notifiable, and the containment steps are the same."}]]},{"t":"h2","id":"afterwards","runs":[{"text":"Afterwards"}]},{"t":"p","runs":[{"text":"Run the postmortem as usual, with two additions: the detection gap in hours, and an honest account of what evidence you did not have and now will. Most security post-incident actions are unglamorous: turn on logging you did not have, remove a credential that should not have existed, restrict a permission that was broader than the job needed. Those are the ones that make the next one smaller."}]}],"check":{"question":[{"text":"You discover an attacker has been using a leaked API key. The instinct is to rebuild the compromised machine immediately from a clean image. Why is that a poor first move?"}],"options":[{"text":[{"text":"Rebuilding does not revoke the key, so access continues"}],"correct":false,"tempting":[{"text":"True and important, but it argues for also revoking, not against preserving; a team could rebuild and revoke together and still have made the mistake."}]},{"text":[{"text":"The clean image may contain the same vulnerability, so the attacker returns"}],"correct":false,"tempting":[{"text":"Plausible if the entry point was a code flaw, but here the entry was a leaked credential, and it still would not be the primary objection."}]},{"text":[{"text":"It destroys the logs and system state needed to establish how they got in and what they reached"}],"correct":true,"tempting":null},{"text":[{"text":"It causes downtime that must be reported to the regulator"}],"correct":false,"tempting":[{"text":"Confuses availability with data protection; notification duties attach to exposure of personal data, not to a maintenance outage."}]}],"order":[0,2,3,1],"why":null},"prev":{"slug":"the-admin-surface","title":"The tools that can do anything","minutes":8},"next":{"slug":"when-somebody-reports-your-users","title":"The email about one of your users","minutes":9}}}