LAW6001 Chap.7 Cybersecurity, Infrastructure and Resilience
Cybersecurity, Infrastructure and Resilience
Duties across the incident
Cybersecurity law allocates responsibility across prevention, detection, reporting, response and recovery. The legal route changes when the event is criminal, state-sponsored, physical-effect or systemic.
This chapter therefore separates threat, critical asset, attribution and resilience before deciding which rules and institutions should respond.
Recovery as governance
Original clinic cases distinguish loss of availability from personal-data exposure and technical indicators from legal attribution. Supplier dependence, continuity and notification remain actionable while attribution is uncertain.
The final move connects every recovery lesson to a changed procurement, architecture or oversight decision.
What this chapter covers
- 01
Criminal, state and systemic threats
- 02
Critical functions and infrastructure
- 03
Confidentiality, integrity and availability
- 04
Technical and legal attribution
- 05
Incident reporting and response
- 06
Recovery, procurement and institutional learning
Worked example · free
Classify a cloud outage before attribution
- 3Classify the failure and affected function.
- 3Separate notification triggers.
- 4Allocate recovery and supplier review.
Key terms
- Critical Infrastructure
- Systems or services whose disruption creates serious consequences beyond the immediate operator.
- Systemic Threat
- Risk arising from defects, concentration or shared dependencies rather than a single malicious actor.
- Technical Attribution
- An evidence-based link between infrastructure, tools and likely actors stated with a confidence level.
- Legal Attribution
- Imputation of conduct to a responsible person or state under an applicable legal rule.
- Operational Resilience
- The capacity to preserve or restore critical functions and change controls after disruption.
Cybersecurity, Infrastructure and Resilience FAQ
Is every cyber incident a data breach?
No. An event may affect confidentiality, integrity, availability or several at once. Service disruption without data access may still trigger operational or sector duties. Analyse each legal notification path separately rather than forcing the entire event into personal-data language.
Why can technical attribution be insufficient?
Technical evidence may identify infrastructure, tools or behaviour associated with an actor, but legal responsibility requires an applicable attribution rule and sufficient evidence for the proposed response. Similar indicators can be copied. State confidence and keep protective action separate from final accusation.
What turns recovery into resilience?
Recovery becomes resilience when evidence changes future decisions. Assign every lesson to an owner, deadline and proof of completion, then alter architecture, procurement, escalation, reporting or oversight. Restoring service without changing the exposed dependency leaves the governance failure in place.
How do I turn a technical incident into a governance analysis?
Describe the essential service and threatened function before listing technical details. Identify the dependency that failed, the actor responsible for managing it, the foreseeable consequence and the control expected before, during or after disruption. Separate prevention, detection, containment, continuity, recovery and learning because each stage has different evidence and owners.
Then ask who receives notice, who can direct emergency action and who reviews decisions once urgency recedes. A backup is not resilience if it is untested; reporting is not accountability if nobody can require remediation; rapid restoration is incomplete if the same supplier concentration remains invisible.
Connect every recommendation to a measurable proof such as exercise results, recovery time, patch evidence, alternative routing or closed corrective actions. End by allocating residual risk to an authorised owner and naming the escalation threshold. This converts a narrative about an attack into a structured account of duty, capacity, evidence and institutional learning.
Exam move
Run each incident through five boxes: threat, asset, attribution, response and recovery. State what is known now and what remains a hypothesis. Split confidentiality, integrity and availability impacts, then list separate notification triggers. Finish with one technical and one governance change. Practise a no-attacker scenario so that cyber analysis does not depend on crime or state attribution.
Build a second scenario in which outage and data theft occur together, then keep the reporting paths separate. Write technical confidence and legal attribution on different lines; add the evidence or rule needed to move from one to the other. Map a supplier incident from procurement through monitoring, containment, continuity and post-incident review.
Place an owner beside every action and reject shared responsibility language that leaves nobody able to decide. For a critical-infrastructure problem, state the function whose loss creates wider consequences rather than relying on the operator's name. For assessment practice, convert each lesson into a control, deadline and proof of completion.
Before the final, retrieve the circuit from memory and ask what can lawfully proceed while attribution remains uncertain. The answer should include protection, evidence preservation, notification analysis and recovery rather than a premature accusation.
Working through Cybersecurity, Infrastructure and Resilience in LAW6001? Sia is AskSia’s AI Law tutor — ask any LAW6001 Cybersecurity, Infrastructure and Resilience question and get a clear, step-by-step explanation grounded in how LAW6001 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.