In the first 72 hours after a breach: stay calm and follow your incident response plan. Contain the incident to stop it spreading, but do so carefully — preserve evidence rather than wiping systems, because you will need it to understand what happened. Engage your incident response capability (internal or an external DFIR firm), convene your response team including legal and communications, and assess the scope. Be aware that notification deadlines may already be running: GCC data-protection laws (PDPL) and financial and critical-infrastructure regulators (CBB, SAMA, NCA and equivalents) impose reporting obligations, often within tight timeframes — involve legal counsel early. Once the incident is contained and investigated, penetration testing verifies that your remediation actually closed the weakness, turning "we think we fixed it" into evidence.
If an attack is active right now: this article is orientation, not a substitute for incident response. Activate your IR plan, engage a DFIR team, and involve legal immediately. Come back for the recovery steps once the immediate situation is under control.
// 01 The first priorities: contain, preserve, assess
The instinct in a breach is panic, and the antidote is a plan. If you have an incident response plan, this is the moment it exists for — follow it. If you do not, the priorities are still clear. First, contain: stop the incident spreading by isolating affected systems, disabling compromised accounts and blocking the attacker's access. Second, preserve evidence: resist the urge to immediately wipe and rebuild, because the logs, memory and disk images you destroy are exactly what you need to understand what happened and to meet regulatory and insurance requirements. Third, assess: work out what was accessed, what data is involved, and how far the compromise reaches.
Throughout, convene the right people early — not just technical staff, but legal, communications and leadership — because a breach is a business and legal event, not only a technical one. Many organisations engage an external digital forensics and incident response (DFIR) firm at this stage; if you have cyber insurance, your policy may require you to use their approved responders, so check it early.
// 02 What not to do
Some well-intentioned reactions make things worse. The common mistakes:
Wiping or rebuilding too soon
Rushing to reimage systems destroys the forensic evidence you need to understand the attack and satisfy regulators and insurers.
Uncoordinated communication
Public statements or customer notifications made before the facts are established, and without legal review, can create liability and confusion.
Tipping off the attacker
Clumsy containment can alert an active attacker to accelerate, destroy evidence or deploy ransomware. Measured, planned containment is safer.
Ignoring notification clocks
Assuming you have time. Regulatory notification deadlines can be short and may already be running from the moment of discovery.
// 03 GCC notification obligations
One of the reasons to involve legal counsel immediately is that you may have reporting obligations with tight deadlines, and they can begin from the moment you become aware of the breach. The picture in the GCC has two layers. The data-protection laws — the PDPL regimes in Bahrain, Saudi Arabia and the UAE — impose breach-notification requirements where personal data is involved. Separately, sector regulators require incident reporting: financial institutions must report to the CBB, SAMA or their equivalents, and government and critical-infrastructure entities to the NCA and national authorities, often within defined timeframes.
The specific deadlines and thresholds vary by country, sector and the nature of the breach, so we will not state a single number here — the right move is to confirm your exact obligations with legal counsel as an early priority, before a deadline passes. What matters is treating notification as a first-day workstream, not an afterthought.
// 04 Where penetration testing fits in recovery
Once the immediate incident is contained and the forensic investigation has established what happened, penetration testing has a specific and valuable role — it is a recovery and assurance step, not an incident-response one. It helps in two ways. First, it can support root-cause understanding by testing the suspected entry path an attacker used, confirming how they got in. Second, and most importantly, it verifies your remediation: once you have closed the weakness that let the attacker in, a targeted test confirms that the fix actually works and that the same or a similar attack no longer succeeds.
This verification matters beyond your own peace of mind. Regulators, customers and insurers will want evidence that you not only responded to the breach but genuinely fixed the underlying weakness — and independent testing provides exactly that. A broader test also surfaces the other weaknesses the attacker did not use this time but could next time, which is why a post-incident engagement often becomes the start of a proper ongoing testing programme. We help organisations at this recovery stage with focused verification testing and, where useful, a wider assessment. Our methodology and report guide explain what you would receive.
// 05 Frequently asked questions
What should you do first after a breach?
Follow your incident response plan. Contain the incident, preserve evidence rather than wiping systems, and engage your IR capability plus legal and communications.
Should you shut everything down?
Not blindly — that can destroy evidence and cause harm. Use measured containment guided by incident responders, while preserving forensics.
What are the GCC notification obligations?
They vary: PDPL data-protection laws and sector regulators (CBB, SAMA, NCA and equivalents) impose reporting, often within tight deadlines. Confirm yours with legal counsel early.
Where does penetration testing fit?
After containment and investigation — to help confirm the entry path and, crucially, verify that your remediation actually closed the weakness.