Incident Response and Information Governance

From information policy to incident response

This coursework covered two parts of information assurance that are closely connected in practice. Information governance defines what an organisation holds, why it holds it, who can use it, and how long it should be retained. Incident response has to preserve and protect that information when systems or accounts are compromised.

I worked through a data-classification exercise, a review of information-governance problems, and a network-intrusion response plan. Together they made policy less abstract: classification changes incident severity, retention affects what evidence exists, and response actions need to account for legal, operational, and communications responsibilities as well as technical containment.

Classifying information

The data-policy exercise used a primary-school case study and divided information into three levels:

Classification	Typical content	Handling position
Restricted	Personal, health, financial, credential, and legally sensitive records	Access limited to specifically authorised roles, with strong storage, transfer, retention, and disposal controls
Confidential	Internal records where exposure could cause operational or reputational harm	Available only to staff or groups with a defined business need
Unrestricted	Deliberately public information	May be shared publicly, subject to accuracy and publishing controls

The case included pupils, families, teachers, administrative staff, catering staff, contractors, and external IT support. Different roles needed access to different slices of the same information. A broad “staff can access school data” rule would not have been enough.

I mapped example data to the classifications:

• contact and family information
• health conditions and support needs
• bank and payroll details
• account credentials
• educational records and progress reports
• internal email
• network and system documentation
• website content, vacancies, and public contact details

The policy’s working matrix was more specific:

Level	Examples	Intended access
Restricted	Home addresses, phone numbers, personal email, photographs, National Insurance numbers, health conditions, employee or contractor bank details, and IT credentials	Head and deputy heads; administration where required; catering staff only for relevant health records
Confidential	Pupil progress and test results, free-school-meal information, network topology, internal staff email, and payroll lists	Faculty, teaching and administration staff according to role; pupils and families only for information relating to them
Unrestricted	Website content, school map, vacancies, and published address or contact details	Public

The matrix exposed why classification and authorisation cannot be the same field. Two records can both be restricted while requiring different role access. Catering staff may need allergy or health information for a pupil without needing the pupil’s family contacts or account data. External IT staff may need system configuration without needing educational records.

The exercise also separated data controllers from processors. The controller decides why and how personal data is processed; a processor handles it on the controller’s behalf. That distinction affects contracts, access decisions, breach response, and accountability.

In the school scenario, senior faculty were identified as the people determining the purpose and means of processing, while teaching and administration staff processed information as part of delivering the service. The policy’s labels were simplified for the exercise, but the distinction forced each dataset to have an accountable purpose rather than existing because a department had always kept it.

Retention and disposal were part of the classification rather than an afterthought. Records should not be kept indefinitely simply because storage is cheap. A useful policy needs a lawful or operational reason for retention, an owner, an expiry or review point, and a reliable disposal method.

The coursework referred to the Pupil’s Educational Records (Scotland) Regulations 2003 and recorded a five-year retention period after the pupil ceased attendance. That is a historical policy example, not a current legal recommendation. It showed how a record category can inherit a specific access and retention obligation that a generic “delete when no longer useful” rule would miss.

For each class of information, I would expect an implementable register to record:

• business and legal purpose
• controller or accountable owner
• systems and locations holding the record
• authorised roles
• processors or external recipients
• retention period and trigger
• disposal method
• encryption, pseudonymisation, or anonymisation requirement
• recovery and evidence requirements

Governance under real operating conditions

The information-governance review examined the gap between a written policy and day-to-day information handling.

Organisations collect data through email, messaging platforms, cloud services, social networks, line-of-business systems, devices, and informal collaboration. The volume and variety make it difficult to know:

• which copy is authoritative
• where sensitive material has moved
• which jurisdiction applies
• whether retention rules were followed
• whether records can be produced for an investigation
• whether staff are recreating information because they cannot find it

The article being reviewed was written in 2013 and described information volume as doubling every eighteen to twenty-four months. It also cited a claim that knowledge workers were interrupted every three minutes and could take half an hour to return to their earlier level of concentration. I treated those as historical claims from the article rather than current measured facts. Their role in the review was to explain the operational cost of uncontrolled records: people spend time searching, switching tools, and recreating information that cannot be found.

The data sources listed in that review reflected its period: telephone messaging, email, Facebook, LinkedIn, Twitter, and other emerging collaboration systems. The technologies have changed, but the governance problem is recognisable. A new communication channel becomes another source of business records, personal data, disclosure obligations, retention decisions, and potential evidence.

Cross-border processing adds further complexity. Privacy law, legal discovery, contractual obligations, and regulatory expectations do not always align neatly. A company may state that it complies with every applicable rule while employees still store records inconsistently or cannot retrieve the material needed for an audit.

The article pre-dated the implementation of GDPR and discussed the then-proposed European reforms against United States discovery expectations. I would not use its legal detail as current guidance. It was useful in showing that the same data may be subject to several jurisdictions and that a global code of conduct does not resolve conflicts automatically.

I took the policy-versus-practice gap into the incident-response work. During an incident, a response team cannot preserve evidence it does not know exists, assess affected data without classification, or explain impact when ownership and retention are unclear.

Incident identification and first questions

The response plan began by defining incident categories:

• denial of service
• compromised credentials
• insider activity
• network intrusion
• ransomware
• policy violation

The category is a starting point, not the final severity. Initial triage needs direct questions:

• When did the activity occur, and when was it detected?
• Who reported it?
• Which systems, networks, departments, and users are involved?
• How was it detected?
• What data or service was targeted?
• What appears to be the objective?
• Is there evidence of an internal or external source?
• Can the current team investigate safely, or is specialist help required?

These questions create the first version of the incident timeline and scope. They also expose what is not yet known.

The incident record should start at first report rather than after confirmation. At minimum it needs a unique reference, reporter, detection source, UTC timestamps, current owner, affected assets, known indicators, confidence level, actions already taken, and links to retained evidence. If the event is later closed as benign, that decision and the evidence supporting it remain part of the record.

Severity and business impact

I built a simple low, medium, and high severity matrix around four factors:

1. the type of system compromised
2. the number of systems involved
3. the sensitivity of accessible data
4. whether the compromise could be used against other systems or organisations

The coursework matrix used these examples:

Question	Low	Medium	High
What was compromised?	Public web or cloud system	Employee or reception workstation	Backend data server or domain controller
How many systems?	One or a few public-facing systems	One or a few internal systems	Multiple systems
What data was accessible?	Public information	User account information	Trade secrets or domain-account information
Could it support another attack?	No identified route	Further compromise inside the organisation	Risk transferred to a trading partner or other organisation

A real incident can span columns. One public server may hold a credential that enables high-impact access; a large number of workstations may be isolated quickly with limited data exposure. The matrix gives responders an initial vocabulary, while the incident manager records why the overall severity was selected and when it changed.

A single public web server and a domain controller should not receive the same response priority. Neither should exposure of already-public content and exposure of privileged credentials or trade secrets.

The matrix was deliberately simple, but it forced technical findings into operational language. A severity decision should explain affected services, user impact, data risk, lateral-movement potential, legal obligations, and the resources required to contain the incident.

Roles and communications

The plan assigned separate responsibilities for technical response, incident coordination, and communications.

The on-call security engineer validates the alert, begins scoping, and starts the technical record. The incident manager coordinates teams, tracks risk and user impact, and keeps the response moving towards a decision. A communications lead prepares internal and external messages with legal, public-relations, customer-support, and business stakeholders.

The original role model separated external communications again. That function reviewed messaging for customers, media, and industry contacts with marketing or public-relations teams after a first factual draft existed. Technical responders supplied confirmed facts; they did not improvise public conclusions while the investigation was still changing.

Status updates should cover:

• current risk
• affected users and services
• confirmed timeline
• containment already completed
• unresolved questions
• next actions and owners

The plan also accounted for the loss of normal communications. If email, chat, identity, or the corporate network is affected, the response team needs a pre-arranged secondary channel and an offline contact list. Building that during the incident is too late.

That secondary channel also needs an access rule. Moving an incident to personal messaging without defining who may join, what may be shared, and how decisions will be retained creates another information-governance problem. The plan should identify the fallback service, activation authority, contact source, and later method for bringing its records into the incident file.

Preparation and detection

The preparation section concentrated on the work needed before a network intrusion:

• maintain current contact details and named backups
• pre-assign technical, legal, HR, support, and communications roles
• define when each team is activated
• keep forensic and replacement technology available
• centralise and protect privileged credentials
• restrict temporary or unnecessary privileged sessions
• make suspicious-activity reporting easy
• run tabletop exercises
• confirm that logs and alerts reach people who can act

The coursework also called for a maintained list of preferred forensic and replacement technology. That meant knowing which acquisition tools, clean systems, spare hardware, storage, and specialist support were available before an incident. A tool list without tested access, licences, media, and trained operators would not meet the same need.

Detection combined automated monitoring with active assessment. The plan referred to endpoint detection, anti-malware controls, user and entity analytics, network monitoring, and host logging. A compromise assessment then determines whether activity is present, how far it has spread, and whether persistence remains active.

The assessment has to test absence as carefully as presence. Finding one known indicator confirms at least one affected point; failing to find that indicator elsewhere does not prove the rest of the estate is clean. Scope expands through identities, remote access, shared infrastructure, administrative tools, network relationships, and time windows until the team has defensible reasons to stop.

Containment, evidence, and recovery

Containment was written as a risk decision rather than an automatic instruction to switch everything off. The response team needs to limit further harm while preserving the evidence required to understand the incident.

Actions in the plan included:

• isolate affected systems, accounts, and data stores
• establish whether sensitive data was accessed or changed
• record every response action with time, owner, and reason
• preserve memory, disks, event logs, packet data, and relevant cloud records
• involve legal or regulatory specialists where required
• remove persistence and close the access path
• reset exposed credentials
• patch affected systems and assess related vulnerabilities
• restore from verified backups
• confirm data integrity before returning services

The source specifically named RAM captures, network logs and packet captures, and hard drives as breach artefacts. Their volatility differs. Live memory and network state can disappear at shutdown; disk and central logs may persist longer but can still roll over or be altered. The response plan therefore needs an acquisition priority based on the incident, not one fixed instruction for every host.

The evidence log is part of the response, not a later paperwork exercise. Containment can alter volatile memory, network connections, timestamps, and process state. Recording what changed helps the forensic team distinguish attacker activity from responder activity.

For each action, the incident record should include the time, operator, system, command or control used, reason, result, and evidence created. It should also retain the original alert, how and when it was discovered, the apparent internal or external source, affected locations, and the current estimate of damage. These were all fields identified in the coursework plan.

Recovery should not stop at making the service available. The plan required checks for data loss, restored-system integrity, remaining indicators, and the health of connected systems. Continued log, memory, and network collection can show whether the attacker attempts to return.

Restoration from backup is also an investigation decision. The team needs to know that the backup predates the compromise, that it is complete, and that restoring it will not reintroduce persistence or the vulnerable configuration. Credential resets, access-path closure, patching, and enterprise-wide vulnerability review sit alongside the rebuild rather than after it.

Post-incident review

The final phase produced an incident report covering affected business areas, the timeline, decisions, technical findings, communications, and recovery.

The review asks:

• what worked as designed
• which evidence was missing
• where ownership or escalation was unclear
• whether staff need further training
• which controls need to change
• whether the scope should remain open
• how lessons will be tracked to completion

Stakeholders should continue receiving updates until the risk and follow-up work are resolved. A post-incident review has limited value if its actions are recorded but never assigned, funded, or tested.

The response plan also called for recurring compromise assessments after the incident. That provides evidence that restored systems remain healthy and tests whether the monitoring changes introduced after the event can detect related behaviour.

This material reflects historical information-assurance coursework and is not current legal or regulatory guidance. Data-protection duties, reporting thresholds, and technical standards change. The operational connection remains: classification and governance determine what an incident affects, while disciplined response preserves the evidence needed to contain it and explain the impact.