What are the incident response requirements under CPCSC?

Answer

CPCSC requires incident detection, documentation, timely reporting to authorities, response support, capability testing, personnel training, and formal incident response plans.

Defining Security Incidents

A security incident is an event that actually or potentially compromises the confidentiality, integrity, or availability of specified information or the systems that handle it. Incidents can include unauthorized access to systems or data where adversaries or unauthorized insiders gain access they shouldn't have.

Malware infections with viruses, ransomware, or spyware affecting systems. Data breaches or exfiltration where specified information is accessed, stolen, or transmitted to unauthorized parties.

Denial of service attacks that disrupt system availability. Social engineering or phishing attacks that successfully compromise credentials or trick users.

Physical security breaches like unauthorized entry to facilities or theft of devices. System misconfiguration or failures that expose specified information.

Not all suspicious events are confirmed incidents—part of incident response is investigating to determine whether an actual compromise occurred or security controls successfully prevented it.

ITSP.10.171 Incident Response Requirements

The Incident Response family in ITSP.10.171 includes several specific requirements that organizations must satisfy.

• You must implement an incident-handling capability consistent with an incident response plan, covering preparation, detection and analysis, containment, eradication, and recovery
• Track and document all system security incidents with sufficient detail for forensics and trend analysis
• Report suspected incidents to the organizational incident response capability within defined time periods—CPCSC requires timely reporting to government authorities, particularly for incidents involving specified information
• Report incident information to defined authorities, which for defence contractors includes notifying the contract technical authority and potentially Public Services and Procurement Canada
• Provide incident response support resources offering advice and assistance to system users
• Test incident response capability effectiveness at defined frequencies through tabletop exercises, simulations, or other testing methods
• Train personnel on incident response responsibilities appropriate to their roles
• Develop and maintain a formal incident response plan

All these requirements work together to ensure organizations can respond effectively when incidents occur.

Privacy Breach Special Requirements

When an incident involves personal information, it becomes a privacy breach with additional notification obligations. Privacy breaches result in loss of control, unauthorized disclosure, unpermitted use, or improper handling of personal information.

If your incident involves a breach of personal information, notification to the contract owner is mandatory under federal privacy laws. Depending on circumstances, notification to affected individuals and the Privacy Commissioner of Canada may also be required.

Defence contractors handling personal information as part of government contracts must understand privacy breach notification requirements under both the Privacy Act (for government institutions) and potentially the Personal Information Protection and Electronic Documents Act (PIPEDA) for private sector organizations.

The intersection of security incident response and privacy breach notification creates complex compliance obligations that incident response plans must address.

Building an Incident Response Capability

Effective incident response requires several organizational capabilities.

• An incident response team with clearly defined roles including incident response coordinator, technical analysts, legal and privacy counsel, communications leads, and executive decision-makers should be established
• Incident detection capabilities through security monitoring, intrusion detection, user reports, antivirus alerts, and anomaly detection help identify incidents promptly
• Investigation capabilities allow forensic examination of affected systems, log analysis, threat intelligence correlation, and determination of incident scope and impact
• Containment procedures quickly isolate affected systems to prevent incident spread, disable compromised accounts, and block malicious traffic
• Eradication capabilities remove adversary presence, patch exploited vulnerabilities, rebuild compromised systems, and address root causes
• Recovery procedures restore systems to normal operations, verify system integrity, and resume business processes
• Post-incident activities conduct lessons-learned reviews, update incident response procedures based on experience, and improve security controls to prevent recurrence

Organizations need all these capabilities, not just isolated pieces.

Incident Detection Challenges

Many organizations struggle most with incident detection—you can't respond to incidents you don't know about. Sophisticated adversaries specifically try to evade detection, sometimes maintaining persistent access for months or years before discovery.

Improving detection requires security information and event management (SIEM) systems that aggregate and analyze logs from across the environment to identify suspicious patterns, endpoint detection and response (EDR) tools that monitor endpoint activity for indicators of compromise, network traffic analysis looking for unusual data flows or command-and-control communications, user behavior analytics identifying anomalous user activities that might indicate compromised accounts, and threat intelligence feeds providing indicators of compromise associated with known threat actors.

Equal importance should be given to employee awareness and reporting—users who recognize and report suspicious emails, unusual system behavior, or other anomalies are often the first line of incident detection.

Incident Classification and Prioritization

Not all incidents have the same severity or urgency. Incident response plans should include classification schemes that categorize incidents by severity based on factors like data sensitivity (does it involve specified information or only non-sensitive data?), system criticality (are mission-critical systems affected?), scope (how many systems or users are impacted?), and potential impact (what's the worst-case damage?).

Classification drives response priorities—a ransomware outbreak affecting systems containing specified information demands immediate all-hands response, while a phishing email that was caught by spam filters and never reached users is documented but may not require urgent response.

Clear classification criteria help responders make consistent decisions under pressure and ensure appropriate resources are deployed to the most serious incidents.

Reporting Timelines and Requirements

CPCSC requires timely incident reporting to government authorities, though specific timelines may vary by contract. Organizations should establish internal reporting requirements including immediate notification to incident response team for high-severity incidents, notification to executive management within hours for incidents involving specified information, notification to contract technical authority within the timeline specified in contract terms (often 24-72 hours), and notification to privacy authorities if personal information is involved, with timelines defined by applicable privacy laws.

Document what information must be included in incident reports such as incident description and timeline, affected systems and data, actions taken to contain and investigate, current status and next steps, and preliminary assessment of information compromised.

Under-reporting or delayed reporting can have serious consequences including contract performance findings, loss of security clearances or certifications, legal liability for privacy breaches, and reputational damage.

When in doubt, report to contract authorities and let them assess significance rather than failing to report an incident that later proves to have been serious.

Testing and Exercising

Organizations often discover incident response plan deficiencies only during actual incidents—a terrible time for unpleasant surprises. Regular testing reveals gaps and builds muscle memory for effective response.

• Tabletop exercises bring the incident response team together to walk through hypothetical scenarios on paper, discussing who would do what and identifying procedural gaps or unclear responsibilities
• Functional exercises simulate actual incident response activities, such as conducting forensics on a deliberately compromised test system or executing communication procedures
• Full-scale exercises simulate major incidents as realistically as possible, with the entire response team executing their roles as if the incident were real
• Red team exercises where security professionals simulate adversary activity to test detection and response provide the most realistic evaluation

Testing should occur at least annually, with more frequent exercises for organizations facing higher risks or those that have experienced recent significant changes.

Common Incident Response Mistakes

Organizations frequently make preventable mistakes during incident response.

• Delayed detection means incidents aren't identified until adversaries have achieved their objectives or caused extensive damage
• Inadequate containment allows incidents to spread while investigation proceeds, amplifying damage
• Poor evidence preservation by shutting down systems or making changes destroys forensic evidence needed to understand what happened
• Communication failures mean stakeholders don't receive timely, accurate information, leading to uncoordinated response or inappropriate decisions
• Inadequate documentation leaves gaps in understanding what occurred and what actions were taken, complicating recovery and lessons-learned analysis
• Failure to involve appropriate expertise by trying to handle incidents internally when specialized forensic or legal expertise is needed wastes time and risks inadequate response

Learning from these common mistakes helps organizations build more effective incident response capabilities.

External Resources and Assistance

Organizations need not face incidents alone—external resources can augment internal capabilities.

• Managed security service providers (MSSPs) can provide 24/7 monitoring and initial incident response capabilities that small organizations can't maintain internally
• Cyber incident response firms offer specialized forensic investigation, malware analysis, and remediation services
• Legal counsel experienced in cyber incidents provides guidance on notification obligations, regulatory compliance, and potential liability
• Cyber insurance may cover incident response costs and provide access to pre-qualified response providers
• Government resources like the Canadian Centre for Cyber Security's Canadian Cyber Incident Response Centre (CCIRC) provide threat intelligence, advice, and coordination during significant incidents

Planning in advance which external resources to engage saves precious time when incidents occur.

Incident Response Documentation

Comprehensive documentation serves multiple purposes during and after incidents.

• Incident timelines recording all significant events, when they occurred, who discovered them, and what actions were taken provide critical context
• System logs, network captures, and forensic images preserve evidence for investigation and potential legal proceedings
• Communications records document what was communicated to whom and when for accountability and coordination
• Decision logs capture why particular response decisions were made for after-action analysis
• Lessons-learned reports synthesize incident experience into actionable improvements

This documentation demonstrates due diligence to regulators and customers, supports continuous improvement of incident response capabilities, provides institutional memory if key personnel depart, and satisfies evidence requirements for CPCSC assessments where assessors will examine how organizations actually handled real incidents.

Recovery and Return to Normal Operations

Incident response doesn't end with eradication—effective recovery ensures systems are restored to secure, trusted states before resuming normal operations.

• Verify that adversary presence is completely eradicated, not just contained, by conducting thorough scans and monitoring for signs of persistent access
• Rebuild compromised systems from known-good baselines rather than simply cleaning infected systems, as sophisticated malware can persist despite cleaning efforts
• Reset credentials for any accounts that may have been compromised, including administrative accounts
• Update security controls to address vulnerabilities or gaps that the incident exploited
• Monitor intensively after recovery for signs of recurrence or related activity
• Validate system integrity and functionality before returning systems to production
• Communicate recovery status to stakeholders including users, customers, and if applicable, government contract authorities

Premature return to operations without thorough recovery can result in reinfection or continued adversary access.

The Business Value of Strong Incident Response

While incident response is often viewed as a cost center, it provides tangible business value.

• Faster detection and response limits damage from incidents, reducing financial impact, operational disruption, and data loss
• Demonstrated incident response capabilities enhance customer and partner confidence that you can protect their information
• Effective incident handling protects reputation by managing communications and demonstrating competent, transparent response
• Reduced recovery time minimizes business disruption and lost revenue
• Lower liability through appropriate breach notification and regulatory compliance fulfills legal obligations
• Improved security posture through lessons learned and continuous improvement strengthens controls based on real-world testing

From this perspective, incident response is insurance and risk management, not just compliance overhead.

Learn More

Additional resources are available to help organizations develop effective incident response capabilities.

• Protecting Specified Information (ITSP.10.171)
• Developing Your Incident Response Plan (ITSAP.40.003)