Table of Contents

(Table of Contents placeholder. Intentionally omitted in this article to reduce length.)

---

1. GOVERN

The Govern function establishes the organisational foundation for incident response. It defines authority, accountability, decision‑making, communication, and oversight. Effective governance ensures that incident response activities are coordinated, compliant, and aligned with TayvenSec’s strategic objectives.

---

Document Control

Document Owner: ICT Management

Version: 1.0 (2026)

Review Cycle: Annual or after any major incident

Approved By: Executive Leadership Team (ELT)

---

1.1 Purpose

The purpose of this Incident Response Plan (IRP) is to provide a structured, repeatable, and effective approach for managing cybersecurity incidents at TayvenSec. The IRP ensures:

• rapid detection and containment
• coordinated response across technical and non‑technical teams
• preservation of evidence
• minimisation of operational, financial, and reputational impact
• compliance with legal and regulatory obligations

---

1.2 Scope

This IRP applies to:

• All TayvenSec information systems
• Cloud services and SaaS platforms
• Networks and hybrid infrastructure
• Endpoints, mobile devices, and remote worker environments
• Identity systems (e.g., Azure AD)
• Applications and data assets
• Personal devices used for work purposes (BYOD)
• All staff, contractors, and approved third‑party service providers

It covers all cybersecurity incidents, regardless of origin, scale, or impact.

---

1.3 Scope Exclusions

This IRP does not cover:

• General IT operational outages
• Non‑security‑related service disruptions
• Routine maintenance events

These are managed under TayvenSec’s IT Service Management (ITSM) processes.

---

1.4 Audience

This IRP is intended for:

• ICT Management
• Cyber Security Team (SOC)
• ICT Operations
• Executive Leadership Team (ELT)
• Human Resources
• Legal
• Communications
• Risk Management
• Approved third‑party responders

---

1.5 Roles and Responsibilities

Incident response requires coordinated action across multiple teams. TayvenSec’s Incident Response Team (IRT) includes technical responders, decision‑makers, and supporting business functions.

Incident Response Roles

Role	Responsibilities	Escalates To	Deputy / Backup
SOC Team Leader (Incident Commander)	Leads incident response, coordinates IRT, manages documentation, approves containment actions.	ICT Management	Senior SOC Analyst
Cyber Security Analysts (SOC)	Investigation, forensics, malware analysis, log analysis, containment, eradication, recovery support.	SOC Team Leader	Another SOC Analyst
External Cyber Security Partners	Specialist support (forensics, malware analysis, threat intelligence).	SOC Team Leader	N/A
Help Desk	Logs initial reports, notifies SOC, communicates with staff.	SOC Team Leader	Help Desk Lead
System Administrators	Server management, backups, patching, remediation.	ICT Management	Senior SysAdmin
Network Administrators	Firewalls, switches, segmentation, network‑level containment.	ICT Management	Senior Network Engineer
Database Administrators	Database recovery, analysis, restoration.	ICT Management	Senior DBA
Software Engineers	Application‑level remediation, secure configuration changes.	ICT Management	Lead Engineer
ICT Management	Operational oversight, major decision approval, resource allocation.	ELT	Deputy ICT Manager
Executive Leadership Team (ELT)	High‑impact decisions, external communications, organisational risk.	N/A	ELT Delegate
Legal Advisor	Legal guidance, regulatory reporting, evidence oversight.	ELT	Legal Associate
Risk Advisor	Organisational risk assessment, alignment with risk frameworks.	ELT	Risk Analyst
Human Resources	Staff behaviour issues, insider threats, policy breaches.	ELT	HR Manager
Communications Lead	Internal/external communications, public statements.	ELT	Communications Officer

---

1.6 Incident Authority & Escalation

TayvenSec uses a tiered escalation model:

• SOC Analyst – identifies and validates incidents
• SOC Team Leader – declares an incident and activates the IRT
• ICT Management – approves major containment actions
• Executive Leadership – approves public communications and regulatory notifications

---

Escalation Timeframes

• SOC Analyst → SOC Team Leader: within 15 minutes of confirming a true positive
• SOC Team Leader → ICT Management: within 30 minutes of incident declaration
• ICT Management → ELT: within 1 hour for High or Critical incidents

All escalation decisions must be documented in the incident log.

---

1.7 Legal, Regulatory, and Reporting Obligations

TayvenSec must comply with:

• Australian Cyber Security Centre (ACSC) reporting requirements
• Privacy Act 1988 (Cth)
• Notifiable Data Breaches (NDB) scheme
• Contractual obligations with clients and partners
• Any relevant industry‑specific regulatory requirements

NDB Scheme Requirement

The NDB scheme requires notification within 30 days of becoming aware of an eligible data breach.

Legal Consultation Required For:

• Data breach notifications
• Law enforcement engagement
• Evidence handling
• Contractual breach implications

---

1.8 Evidence Handling & Chain of Custody (Governance Requirements)

TayvenSec must ensure that all evidence collected during an incident is:

• Preserved
• Documented
• Protected from tampering
• Stored securely
• Handled only by authorised personnel

Authorisation Requirement

Evidence must not be collected from a live system without authorisation from the SOC Team Leader or Legal Advisor.

Chain‑of‑Custody Documentation Must Include:

• Who collected the evidence
• When it was collected
• Where it was stored
• Who accessed it
• Any transfers of custody

Operational execution of evidence preservation occurs under Respond (Section 5.9).

---

1.9 Governance Oversight of Continuous Improvement

While continuous improvement activities are executed under Identify (ID.IM), governance ensures:

• Accountability
• Resourcing
• Policy updates
• Executive visibility
• Periodic IRP reviews
• Alignment with organisational risk appetite
• Tracking of improvement actions to completion

Governance Mechanism

Governance oversight is executed through a quarterly IRP review meeting chaired by ICT Management, with ELT sign‑off on major changes and improvement actions.

---

2. IDENTIFY

The Identify function ensures that TayvenSec understands its environment, assets, risks, and potential impacts. It establishes the foundational knowledge required for effective detection, response, and recovery. Identify also includes the Continuous Improvement (ID.IM) category, which integrates lessons learned back into organisational preparedness and risk management.

---

2.1 Asset Awareness & Critical Systems

TayvenSec maintains an up‑to‑date understanding of all assets relevant to incident response through:

• A centralised Configuration Management Database (CMDB)
• Automated cloud and endpoint discovery tools
• Quarterly asset validation by ICT Operations
• Integration with cloud provider asset inventories

Assets tracked include:

• Critical business systems
• Cloud services and SaaS platforms
• Network infrastructure
• Endpoints and mobile devices
• Identity systems
• Data repositories
• Third‑party and supply chain dependencies

This structured approach enables accurate impact assessment and prioritisation during incidents.

---

2.2 Data Classification & Business Impact

TayvenSec uses a three‑tier data classification model:

Data Classification Levels

Level	Definition	Examples
Confidential	Regulated, sensitive, or client data; unauthorised disclosure could cause significant harm.	Client vulnerability reports, personal data, credentials
Internal	Operational business data not intended for public release.	Internal project docs, system configuration notes
Public	Information approved for external distribution.	Published blog posts, marketing material

Classification informs:

• Severity assessment
• Containment priorities
• Legal and regulatory obligations
• Communication requirements
• Evidence handling procedures

2.2.2 Mapping to Government Protective Markings (If Applicable)

TayvenSec Level	NSW Gov Equivalent	Aus Gov PSPF Equivalent
Confidential	OFFICIAL: Sensitive / Protected	OFFICIAL: Sensitive / PROTECTED
Internal	OFFICIAL	OFFICIAL
Public	PUBLIC	PUBLIC

---

2.3 Threat Landscape & Attack Types

TayvenSec evaluates threats using the Confidentiality, Integrity, and Availability (CIA) triad. Common attack types and their typical CIA impacts include:

CIA Impact Matrix

Attack Type	Confidentiality	Integrity	Availability
Ransomware	✔	✔	✔
DDoS	–	–	✔
Malware & Viruses	–	✔	✔
Phishing	✔	–	–
Social Engineering	✔	–	–
Insider Threats	✔	✔	–
Supply Chain Attacks	✔	✔	–

Understanding these impacts supports accurate risk assessment and response prioritisation.

---

2.4 Incident Severity Matrix

TayvenSec uses a simplified three‑tier severity model for clarity and operational speed. Response timeframes align with escalation requirements defined in Section 1.6.

Severity Levels

Level	Definition	Examples	Response Timeframe
High	Major operational disruption; significant financial, legal, or reputational impact.	Ransomware, DDoS, malware outbreak, financial fraud.	Within 15 minutes
Medium	Limited disruption; minor financial or reputational impact.	Credential theft, targeted phishing.	Within 1 hour
Low	No disruption; informational alerts only.	Blocked phishing, unsuccessful brute‑force attempts.	Within 24 hours

Severity determines escalation, communication, and response requirements.

---

2.5 Monitoring for Indicators of Compromise (IOCs)

TayvenSec monitors multiple sources for signs of compromise to support early detection and situational awareness.

Monitoring Sources

Source	Type	Description	Frequency / Retention
SIEM & XDR	Alerts	Aggregates logs and detects suspicious activity.	Real‑time / 12 months
Antivirus / EDR	Alerts	Detects malware and endpoint threats.	Real‑time / 180 days
Firewall & Network Logs	Logs	Shows inbound/outbound traffic patterns and anomalies.	Real‑time / 180 days
Server & Desktop Logs	Logs	Records system activity and authentication events.	Daily / 180 days
Cybersecurity News & Threat Intel	External Intel	Awareness of emerging threats and vulnerabilities.	Daily / N/A
Internal Staff Reports	Local Info	Users may observe unusual behaviour.	As reported
Public Reports	Local Info	External users may report issues with TayvenSec services.	As reported

---

2.6 Incident Intake & Identification Workflow

Incidents may be identified through:

• user reports
• help desk observations
• SOC alerts
• threat hunting
• automated detection tools

Identification Workflow

Task	Description	Responsible Team
Incident detected	Suspicious activity identified.	Staff, Help Desk, SOC, Ops
Ticket logged	Incident recorded in ITSM system.	Help Desk
SOC notified	SOC receives alert and begins triage.	Help Desk, SOC, Ops
False positive determination	SOC assesses whether activity is malicious. If false positive, ticket is closed.	SOC
Severity assessed	SOC applies severity matrix.	SOC
ICT Management informed	Management briefed on severity and scope.	SOC Team Leader
Risk assessment	Organisational risk evaluated.	SOC Lead & ICT Management
War room activated	Virtual or physical meeting space established.	SOC Lead
IRT convened	Relevant stakeholders join.	All
Communications activated	Approved messages prepared and sent.	Communications Lead
Tasks assigned	IRT roles allocated.	ICT Management
Documentation updated	Ticket updated with decisions and actions.	SOC Lead

---

2.7 Third‑Party & Supply Chain Dependencies

TayvenSec tracks third‑party dependencies through:

• The CMDB
• Vendor risk assessments
• Contract registers
• Cloud provider dashboards

Third‑Party Incident Process

• The SOC Team Leader notifies relevant third‑party providers when an incident involves their systems or services.
• Notification occurs within 30 minutes for High‑severity incidents.
• Third‑party SLAs and contractual obligations guide expected response times.
• All communications with vendors are logged in the incident record.

This ensures coordinated response across the supply chain.

---

2.8 Continuous Improvement (ID.IM)

Continuous Improvement is part of the Identify function under NIST CSF 2.0 (ID.IM). CSF 2.0 treats improvement as a foundational capability, not a post‑incident afterthought. By placing Continuous Improvement within Identify, TayvenSec reinforces that lessons learned, capability uplift, and governance feedback loops are core elements of incident readiness.

A mature IR capability is defined by how effectively it evolves. Continuous Improvement ensures TayvenSec strengthens controls, improves processes, and becomes more resilient after every incident.

Lessons Learned Activities

• Reviewing what happened
• Analysing root causes
• Identifying gaps
• Updating the IRP
• Improving controls
• Enhancing training
• Updating asset inventories
• Refining detection rules
• Updating risk register entries
• Validating corrective actions

Timeframe

The Lessons Learned process must begin within 5 business days, consistent with Section 2.8.

---

2.8.1 After‑Action Review Process

TayvenSec conducts two structured review activities after every incident.

Hot Wash (within 24–48 hours)

A rapid, informal debrief focused on:

• what happened
• what worked
• what failed
• immediate observations
• operational or emotional friction points

The goal is to capture raw insights while the incident is still fresh.

Formal Post‑Incident Review (PIR)

A structured, documented review completed within 5 business days of incident closure.

The PIR includes:

• incident timeline
• root cause analysis
• control failures and gaps
• communication effectiveness
• response delays
• containment and recovery performance
• recommendations for improvement

---

2.8.2 Incident Reporting Template

TayvenSec uses a standardised incident reporting template to ensure consistency and reduce cognitive load during high‑pressure situations.

The template includes:

• incident summary
• severity classification
• affected systems and data
• timeline of events
• actions taken
• evidence collected
• communication log
• root cause
• lessons learned
• remediation actions
• ownership and deadlines

---

2.8.3 Root Cause Analysis Requirements

Every Medium and High severity incident requires a formal Root Cause Analysis (RCA).

Approved RCA Methods

• Five Whys – effective for human‑process failures
• Contributing Factors Analysis – ideal for complex technical incidents

RCA Outputs Must:

• identify the primary cause
• identify contributing causes
• map each cause to a failed or missing control
• recommend specific improvements

Low Severity Incidents

Low severity incidents do not require individual RCAs. Instead, they are reviewed collectively during quarterly security meetings to identify patterns, recurring issues, and systemic weaknesses.

---

2.8.4 Control Improvements and Remediation Tracking

Lessons learned must translate into implemented changes.

TayvenSec maintains a Remediation Register that tracks:

• identified issues
• recommended improvements
• control owners
• deadlines
• status (open, in progress, blocked, complete)
• risk rating
• verification evidence

Governance Requirements

• ICT Management owns the remediation register
• SOC validates technical control improvements
• Risk Advisor updates the organisational risk register
• Executive Leadership receives quarterly remediation reports

This prevents “PIR theatre” where issues are identified but never fixed.

---

2.8.5 IRP Update and Governance Review Cycle

The IRP must evolve with the organisation, not lag behind it.

IRP Review Requirements

• annual full review by ICT Management, SOC, and Risk Advisor
• post‑incident updates after every Medium or High severity incident
• version control maintained by ICT Management
• executive approval required for major revisions

Governance Alignment

The IRP review cycle ensures alignment with:

• NIST CSF 2.0
• ACSC Essential Eight
• organisational risk appetite
• technology changes
• regulatory obligations
• lessons learned from real incidents

Continuous Improvement ensures TayvenSec becomes more resilient with every incident, not just compliant.

---

3. PROTECT

The Protect function focuses on proactive measures that reduce the likelihood and impact of cybersecurity incidents. These controls strengthen TayvenSec’s resilience, limit attacker movement, and support rapid response.

---

3.1 Preventive Security Controls

TayvenSec maintains a baseline of preventive controls aligned to industry standards (CIS Benchmarks, Microsoft Security Baselines, ASD Essential Eight). Preventive controls are reviewed quarterly and enforced through change management.

Ownership: ICT Management owns the preventive control baseline. The SOC monitors compliance through continuous security tooling and quarterly reviews.

Core Preventive Controls

• Firewalls with rule‑review cycles
• Endpoint protection and EDR
• Secure configuration baselines
• Network segmentation and micro‑segmentation
• Identity and access management (IAM)
• MFA enforcement across all accounts
• Conditional access policies
• Patch management and configuration hardening
• Email and web filtering
• Zero Trust access principles

These controls reduce attack surface and limit lateral movement.

---

3.2 Backup & Recovery Readiness

TayvenSec maintains a robust, multi‑layered backup strategy to ensure recoverability during incidents.

Backup Strategy Includes

• Full and incremental backups
• Offsite and cloud replication
• Immutable backup storage
• Snapshot technologies for rapid restoration
• Quarterly backup testing
• Documented backup retention schedules
• 3‑2‑1‑1 rule: 3 copies, 2 media types, 1 offsite, 1 immutable

Recovery Objectives

System Type	RTO	RPO
Critical Systems	4 hours	4 hours
Non‑Critical Systems	24 hours	24 hours

Backup Test Failures

Failed backup tests are:

• Logged in the ITSM system
• Escalated to ICT Management
• Remediated within 5 business days

Backups must be validated for compromise before restoration to prevent reinfection.

---

3.3 Patch & Vulnerability Management

TayvenSec applies a structured, risk‑based patching and vulnerability management process.

Ownership:

• ICT Operations owns patch deployment.
• SOC owns vulnerability identification, prioritisation, and verification.

Patching Timeframes

• Critical security patches: within 48 hours
• High‑severity patches: within 7 days
• Medium‑severity patches: within 30 days
• Low‑severity patches: within 90 days

Vulnerability Management Includes

• Weekly vulnerability scanning
• Monthly configuration compliance checks
• Firmware updates for network and server hardware
• Emergency patching procedures for zero‑day threats
• Remediation tracking through the risk register

Exceptions

If a patch cannot be applied within the required timeframe:

• compensating controls must be implemented, or
• formal risk acceptance must be documented

All risk acceptances and compensating controls are recorded in the organisational risk register.

---

3.4 Access Control & Identity Security

Identity is a primary attack vector. TayvenSec applies Zero Trust principles to identity and access management.

Identity Security Controls

• Least‑privilege access
• Privileged access management (PAM)
• Conditional access policies
• MFA enforcement for all accounts
• Passwordless authentication where supported
• Rapid deactivation of compromised or unused accounts
• Quarterly access reviews
• Monitoring for anomalous authentication behaviour

Service Account Governance

• Credential vaulting
• Least‑privilege permissions
• Monitoring for misuse
• Credential rotation at least every 90 days
• Immediate rotation after suspected compromise

Identity governance ensures access is appropriate, monitored, and revocable at any time.

---

3.5 Cybersecurity Training & Awareness

Training ensures staff can recognise threats and respond appropriately. TayvenSec maintains a structured training program with defined frequencies.

Training Programs

Training	Description	Audience	Frequency
Security Awareness Training	Phishing simulations, mandatory training modules.	All staff	Annual + ongoing phishing simulations
Incident Handler Certification	Technical IR training.	SOC Team	Annual
SOC Technical Training	Log analysis, forensics, SIEM, malware analysis.	SOC Team	Annual
IRP Walkthroughs	Internal briefings on IRP updates.	IRT	Semi‑annual
Tabletop Exercises	Simulated incidents to test readiness.	All stakeholders	Annual + after major incidents

Training ensures consistent readiness across the organisation.

---

3.6 Incident Response Resources

TayvenSec maintains a secure, access‑controlled repository containing all resources required for rapid incident response.

Access: Restricted to SOC, ICT Management, and IRT members.

IR Resources Include

• IRP documentation
• Network diagrams
• System inventories
• Forensics tools and checklists
• Communication templates
• SIEM dashboards
• Threat intelligence feeds
• Escalation contacts
• Vendor support details

These resources are reviewed quarterly to ensure accuracy.

---

3.7 Incident Response Tools

TayvenSec maintains a curated toolkit for investigation, forensics, and remediation. For public release, tools are described by category rather than product name.

Tool Categories

• Forensics tools (disk, memory, and artifact analysis)
• Network analysis tools (packet capture, traffic inspection)
• Endpoint analysis tools (EDR consoles, log collectors)
• Penetration testing and assessment tools (vulnerability scanning, exploitation frameworks)
• Imaging and evidence acquisition tools (disk imaging, memory capture)

Tools are stored in a secure repository, with licensing and updates managed by ICT Operations.

---

3.8 Email & Web Security Controls

Email and web traffic are primary attack vectors. TayvenSec enforces:

• Advanced email filtering
• Attachment sandboxing
• URL rewriting and scanning
• DMARC, DKIM, and SPF enforcement
• Blocking of high‑risk file types
• Web content filtering
• Anti‑spoofing protections

These controls significantly reduce phishing and malware delivery risks.

---

3.9 Hardening Standards

TayvenSec applies hardening standards across all systems, including:

• CIS Benchmarks
• Microsoft Security Baselines
• Cloud provider hardening guides (AWS, Azure, M365)
• Secure configuration templates for servers, endpoints, and network devices

Ownership: ICT Operations owns the maintenance and review of hardening standards, with SOC providing oversight through configuration compliance checks.

Review Cycle: Hardening standards are reviewed annually or after major platform changes.

---

4. DETECT

The Detect function ensures that TayvenSec can rapidly identify anomalous activity, confirm potential incidents, and escalate appropriately. Effective detection reduces attacker dwell time, supports early containment, and enables coordinated response.

Ownership:

• SOC: detection operations, alert triage, incident validation
• ICT Management: detection tooling, log pipelines, platform availability
• Detection Engineering (SOC): alert logic, tuning, false‑positive reduction

---

4.1 Detection Methods & Alerting Sources

TayvenSec uses multiple detection mechanisms to ensure broad visibility across its digital environment. These sources are reviewed quarterly to ensure accuracy, coverage, and relevance.

Detection Sources

• Security Information and Event Management (SIEM)
• Extended Detection and Response (XDR)
• Endpoint Detection and Response (EDR)
• Firewall and network telemetry
• Cloud security logs (Azure, AWS, SaaS platforms)
• Identity logs (Azure AD / Entra ID)
• Threat intelligence feeds
• User and Entity Behaviour Analytics (UEBA)
• Staff reports and help desk escalations

Detection Pipeline Health

The SOC continuously monitors detection pipeline health, including:

• Log ingestion
• Connector status
• Sensor availability
• Alert‑rule execution

Any detection gaps or offline sources are immediately escalated to ICT Management.

Detection SLAs

• High‑severity alerts: triaged within 15 minutes
• Medium‑severity alerts: triaged within 1 hour
• Low‑severity alerts: triaged within 24 hours

These SLAs align with the severity response timeframes defined in Section 2.4.

---

4.2 Triage Workflow

When an alert is generated, the SOC follows a structured triage workflow to validate, classify, and escalate potential incidents.

Triage Steps

1. Initial Review (SOC Analyst)
   • Validate whether the alert is a true positive
   • Assess severity and potential impact
   • Identify affected systems, accounts, or data
2. Correlation with Additional Data Sources
   • SIEM logs
   • Endpoint telemetry
   • Network activity
   • Authentication logs
   • Threat intelligence indicators
   • Cloud audit logs
3. Decision Point: False Positive or Incident
   • If false positive → ticket closed with documented justification
   • If true positive → proceed to incident classification
4. Escalation
   • SOC Analyst escalates confirmed incidents to the SOC Team Leader
   • Escalation must occur within the timeframe defined in Section 1.6
5. Documentation
   • All triage actions, evidence, and decisions recorded in the incident ticket
   • Ticket must include timestamps, analyst notes, and correlation findings

Unresolved Alert Escalation

Alerts that remain unresolved after double their SLA window are automatically escalated to the SOC Team Leader for decision.

This prevents alert stagnation and ensures timely action.

---

4.3 Incident Classification & Prioritisation

Incidents are classified using the severity matrix defined in Identify (Section 2.4). Classification determines:

• Escalation path
• Communication requirements
• Containment urgency
• Resource allocation
• War room activation
• Regulatory reporting triggers

Severity Overrides

Severity classifications may only be overridden by:

• the SOC Team Leader, or
• ICT Management

All overrides must be documented with justification in the incident ticket.

---

4.4 War Room Activation Criteria

A war room (virtual or physical) is activated when:

• The incident is classified as Medium or High
• Multiple systems or users are affected
• Sensitive or regulated data may be compromised
• External reporting may be required
• Coordinated multi‑team response is needed
• Attacker activity is ongoing or spreading

Ownership: The SOC Team Leader activates the war room and notifies all IRT members.

War Room Stand‑Down Criteria

The SOC Team Leader may stand down the war room when:

• Containment is achieved
• Attacker activity has ceased
• No further coordinated response is required
• All teams have transitioned to recovery or monitoring

Stand‑down decisions must be documented in the incident ticket.

---

4.5 Initial Notification Procedures

Upon confirming an incident, the SOC Team Leader initiates the notification process.

Notification Flow

• SOC notifies ICT Management
• ICT Management notifies Executive Leadership (for Medium/High incidents)
• Communications Lead prepares internal and external messaging
• Legal Advisor assesses regulatory reporting obligations
• Third‑party providers notified if their systems or services are involved

NDB Timing Clarification

Legal must assess whether the NDB 30‑day notification window has already commenced based on the earliest point of awareness.

Notifications must be:

• timely
• accurate
• aligned with approved communication protocols
• documented in the incident ticket

---

4.6 Logging Requirements During an Incident

During active incidents, TayvenSec ensures log integrity, retention, and evidentiary value.

Logging Requirements

• All relevant logs are preserved
• SIEM retention windows are extended as needed
• Log forwarding pipelines are validated
• Time synchronisation (NTP) is confirmed
• Evidence is exported and stored securely
• Access to logs and evidence is restricted to authorised personnel
• Chain‑of‑custody documentation is maintained

Missing or Tampered Logs

Missing, incomplete, or tampered logs trigger immediate escalation to:

• ICT Management
• Legal

This may indicate attacker activity, system compromise, or compliance impact.

---

5. RESPOND

The Respond function stabilises the incident, contains the threat, coordinates communication, and preserves evidence. This phase determines whether the incident is resolved quickly or escalates into a prolonged disruption.

Ownership:

• SOC: technical response, containment, investigation
• ICT Management: operational decision‑making, resource allocation
• Communications Lead: internal and external messaging
• Legal Advisor: regulatory and compliance oversight
• IRT (Incident Response Team): coordinated execution of response actions

---

5.1 Response Objectives

TayvenSec’s response objectives are to:

• Contain the threat
• Minimise operational impact
• Preserve evidence
• Eradicate the attacker
• Maintain communication clarity
• Protect staff and customers
• Comply with legal and regulatory obligations
• Support rapid recovery

Objective Prioritisation

The SOC Team Leader prioritises response objectives based on incident type. Where containment and evidence preservation conflict, containment may take precedence only when delay would cause material harm.

---

5.2 Initial Response Actions

Upon incident confirmation, the SOC Team Leader initiates the response phase.

Initial Actions

• Activate the IRT
• Establish the war room
• Assign roles and responsibilities
• Validate severity and scope
• Initiate containment planning
• Preserve initial evidence
• Confirm detection sources remain operational
• Notify ICT Management

Timeframe

Initial response actions must be completed within the escalation window for the declared severity level (see Section 1.6).

---

5.3 Containment Strategies

Containment aims to limit damage and prevent further compromise. TayvenSec applies both short‑term and long‑term containment strategies.

Short‑Term Containment

• Isolating affected systems
• Disabling compromised accounts
• Blocking malicious IPs, domains, or URLs
• Restricting network segments
• Disabling services or servers
• Applying temporary firewall rules
• Removing devices from the network

Long‑Term Containment

• Applying patches or configuration changes
• Resetting credentials
• Rebuilding compromised systems
• Implementing additional monitoring
• Tightening access controls

Approval Requirements

High‑severity containment actions require approval from ICT Management.

Delegated Authority

If ICT Management is unavailable and delay would cause material harm, the SOC Team Leader may approve emergency containment actions, with immediate retrospective notification to ICT Management.

---

5.4 Investigation & Analysis Procedures

The SOC performs detailed investigation to determine the nature and scope of the incident.

Investigation Activities

• Log analysis
• Malware analysis
• Endpoint forensics
• Network forensics
• Cloud audit log review
• User activity analysis
• Threat intelligence correlation
• Timeline reconstruction

Investigation Goals

• Root cause
• Attack vector
• Scope of compromise
• Affected systems
• Data exposure
• Attacker behaviour
• Persistence mechanisms

Update Cadence

• High‑severity incidents: investigation updates provided to the IRT every 2 hours
• Medium‑severity incidents: updates provided every 4 hours

Findings must be documented in the incident ticket and shared with the IRT.

---

5.5 Communication Plan

Communication during incidents must be:

• Accurate
• Timely
• Approved
• Consistent
• Aligned with legal requirements

Internal Communications

• Staff notifications
• ICT updates
• Executive briefings
• IRT coordination messages

External Communications

• Customer notifications
• Public statements
• Regulatory reporting
• Media responses
• Cyber insurance provider notifications

Only the Communications Lead and Executive Leadership may issue external statements.

Communication Frequency

• High‑severity incidents: internal and executive updates at least every 2 hours
• Medium‑severity incidents: updates at least every 4 hours

Regulatory Timing

Legal must determine whether regulatory notification windows (e.g., NDB 30‑day requirement) have already commenced based on the earliest point of awareness.

---

5.6 Decision‑Making Framework

Key decisions include:

• Declaring an incident
• Activating the IRT
• Approving containment actions
• Engaging external responders
• Notifying regulators
• Isolating systems (containment)
• Shutting down systems (executive decision)
• Restoring services

Decision authority follows the escalation model defined in Govern (Section 1.6).

Decision Logging

All decisions must be:

• Timestamped
• Attributed to a decision‑maker
• Justified
• Recorded in the incident ticket

---

5.7 Coordination with External Stakeholders

External coordination may involve:

• Managed security providers
• Cloud service providers
• Law enforcement
• Regulators
• Cyber insurance providers
• Incident response vendors

Engagement must be approved by ICT Management or Executive Leadership. All external communications must be logged.

---

5.8 Documentation Requirements During Response

All actions must be documented, including:

• Timestamps
• Decisions
• Containment steps
• Evidence collected
• Communications sent
• System changes
• Meeting minutes
• War room updates

Documentation Ownership

The SOC Lead is responsible for ensuring all documentation is maintained throughout the incident.

Accurate documentation supports:

• Legal defensibility
• Insurance claims
• Lessons learned
• Compliance reporting

---

5.9 Evidence Preservation & Forensic Integrity

Evidence must be preserved in accordance with governance requirements and forensic best practices.

Evidence Types

• Disk images
• Memory captures
• Log exports
• Network packet captures
• Screenshots
• Configuration snapshots
• Forensic notes

Integrity Requirements

• Evidence must be stored in secure, access‑controlled locations
• Hash values must be generated and recorded
• Hardware or software write blockers must be used during disk imaging
• Chain‑of‑custody documentation must be maintained
• Evidence must not be altered during collection or analysis

Evidence integrity is essential for legal defensibility, insurance claims, and post‑incident review.

---

6. RECOVER

The Recover function restores normal operations, validates system integrity, and ensures that TayvenSec emerges from the incident in a stronger, more resilient state. Recovery is not simply about restoring systems, it is about restoring confidence, stability, and operational continuity.

Ownership:

• ICT Operations: system restoration, backup recovery, configuration hardening
• SOC: validation, monitoring, threat eradication confirmation
• ICT Management: restoration prioritisation, business coordination
• Communications Lead: recovery‑phase messaging
• IRT: coordinated execution of recovery activities

---

6.1 Recovery Objectives

TayvenSec’s recovery objectives are to:

• Restore systems and services safely
• Validate that threats have been fully eradicated
• Ensure restored systems are hardened
• Confirm data integrity
• Communicate effectively with stakeholders
• Resume normal business operations
• Initiate transition to the Lessons Learned process

Objective Prioritisation

The SOC Team Leader and ICT Management jointly prioritise recovery objectives based on:

• Business impact
• System criticality
• Regulatory obligations
• Residual risk

---

6.2 Recovery Planning

Recovery begins only after:

• Eradication is confirmed
• Systems are validated as clean
• Backups are verified as uncompromised
• Containment measures are stable

Recovery Planning Activities

• Prioritising system restoration
• Coordinating with system owners
• Validating backup integrity
• Scheduling restoration windows
• Ensuring minimal business disruption
• Confirming resource availability

Business Communication

Before restoration begins, ICT Management briefs relevant business units on:

• Restoration order
• Expected downtime
• Operational impacts
• Communication channels

Timeframe

Recovery planning must begin immediately after eradication is confirmed and be completed within the severity‑based escalation window defined in Section 1.6.

---

6.3 Backup Validation & Restoration

Before restoring any system, TayvenSec follows a structured validation and restoration workflow.

1. Verify Backup Integrity

• Scan backups for malware
• Confirm timestamps and completeness
• Validate that no indicators of compromise exist
• Confirm backup source meets RPO requirements

2. Restore Systems

• Use full backups or snapshots
• Restore configurations, databases, and files
• Validate system functionality
• Confirm restored systems match baseline configurations

3. Document Restoration Actions

• Record what was restored
• Capture timestamps
• Note deviations from standard procedures
• Document failed restoration attempts

Backup Failure Handling

If a backup fails validation:

• ICT Operations escalates to ICT Management
• Alternative restoration sources are identified
• Failure is recorded in the risk register
• Corrective actions are initiated

If No Valid Backup Exists

If no clean backup is available:

• Systems may be rebuilt from scratch
• Cloud or vendor‑provided restoration options may be used
• Data reconstruction may occur using logs, exports, or unaffected systems
• The incident is escalated to Executive Leadership due to business impact

---

6.4 System Hardening Post‑Restoration

After restoration, systems must be hardened to prevent reinfection.

Hardening Requirements

• Apply all security patches
• Update configurations
• Enforce MFA
• Remove unused accounts
• Reset passwords
• Validate firewall rules
• Re‑enable monitoring and alerting
• Confirm endpoint protection is active
• Validate system against CIS or vendor baselines

Ownership

ICT Operations performs hardening; SOC validates compliance.

---

6.5 Monitoring During Recovery

The SOC monitors restored systems for:

• Unusual authentication activity
• Malware reappearance
• Suspicious network traffic
• Configuration changes
• Privilege escalation attempts
• Re‑establishment of persistence mechanisms

Monitoring Duration

Monitoring continues until:

• No suspicious activity is detected for a minimum 72‑hour stability window, and
• The SOC Team Leader confirms system stability

Extension Authority

If suspicious activity occurs during the stability window:

• The monitoring period automatically resets, and
• The SOC Team Leader may extend monitoring as required

---

6.6 Stand‑Down Procedures

Once recovery is complete:

• The IRT is formally stood down
• All temporary containment controls are reviewed and either removed or converted into permanent controls
• Normal operations resume
• Documentation is finalised
• Communications are issued to staff and stakeholders

Stand‑Down Authority

Stand‑down occurs only after approval from Executive Leadership, based on recommendations from:

• SOC Team Leader
• ICT Management

---

6.7 Post‑Incident Communications

Communications may include:

• Internal notifications
• Customer updates
• Regulatory reporting
• Public statements (if required)

Approval Requirements

All communications must be approved by:

• Communications Lead
• Legal Advisor
• Executive Leadership

Regulatory Considerations

Legal must confirm whether:

• NDB reporting is required
• Contractual reporting obligations apply
• Insurance notification windows are triggered

---

Conclusion

Cybersecurity incidents are no longer rare disruptions they are an operational certainty. What separates resilient organisations from vulnerable ones is not the absence of incidents, but the presence of a disciplined, well‑governed, and continuously improving response capability.

This Incident Response Plan provides TayvenSec with a modern, NIST CSF 2.0–aligned framework for managing incidents across their full lifecycle: Govern, Identify, Protect, Detect, Respond and Recover. It integrates technical procedures, communication pathways, decision‑making authority, and organisational governance into a single, coherent structure that can be executed under pressure.

A strong IRP is not static. It evolves with:

• Emerging threats
• New technologies
• Changes in business operations
• Regulatory shifts
• Lessons learned from real incidents

By adopting this plan and by committing to the continuous improvement practices defined in Section 2.8, TayvenSec ensures that every incident strengthens the organisation rather than weakens it. Each response becomes faster, clearer, more coordinated, and more effective than the last.

This IRP is more than a document. It is a capability. A commitment. And a foundation for long‑term resilience.

TayvenSec is now positioned not only to withstand cybersecurity incidents, but to emerge from them stronger, smarter, and more secure than before.

References

Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile

NIST Cyber Security Framework

The NIST Cybersecurity Framework (CSF) 2.0 Documentation

Continue Reading

Check out my other articles! If you enjoyed this one, you’ll probably like the rest of my cyber stories, guides, and breakdowns too.

How to Write a Modern Incident Response Plan (IRP) Using NIST CSF 2.0

The Evolution of Incident Response: Updating the Classic NIST IRP to the 2026 Framework

How to Build a Vulnerability Management Program

How to Build a Cyber Aware Workplace Culture