Finance and insurance
The financial sector is more densely regulated than almost any other, and the supervisor asks not only whether security exists but whether it has demonstrably been tested. That moves the emphasis from a list of weaknesses to a scenario.
The way in leads through people and third parties
Attacks on financial companies rarely begin with a technical gap in the core system. They begin with a credible message to a person, with stolen credentials of a service provider, or with a portal that gives away more than intended.
The pattern in the known cases is the same: the attackers obtain a valid access, then move on with legitimate tools, and for that reason go unnoticed for weeks. What is noticed in the end is the payment or the data leaving, not the break-in.
For the defence that means the decisive figure is not the number of weaknesses closed but the time to detection. And that cannot be estimated, only measured.
Attack, detection, evidence
The three interlock: a test without measuring detection does not answer the supervisory question.
Attack realistically
Scenario-based red team exercises along plausible attacker profiles, with phishing and social engineering as the way in and clearly agreed limits. Supplemented by the external attack surface: portals, payment interfaces, authentication.
Measure detection
Was the activity noticed, how long did it take, and which data sources were missing. That analysis is the actual return from an exercise, not the list of techniques used.
Produce evidence
A report describing the resilience of a critical function, not twenty individual findings. That is the form in which the supervisor asked the question.
How a red team exercise runs
A red team works towards a goal and over weeks, not days. What is agreed is an objective, for instance access to a critical function, not a list of systems to test. The route there stays open, because that is exactly where the insight lies.
Third parties and outsourced functions are a regular route in, not a special case. Whoever has production access belongs in the scenario, with limits agreed beforehand.
The measurement on the defence side runs alongside. Every step is timestamped so that afterwards it can be said precisely where something was seen and where it was not.
How a security operations centre is built
The effort does not sit in the platform but in the use cases. Sources from network, endpoints, identity and cloud are normalised onto one schema and enriched before the first rule is written.
The detection itself is versioned and measured against its coverage under MITRE ATT&CK, so that it stays visible which techniques would be caught and which would not. What slips through in an exercise becomes the next use case. That feedback loop is what decides whether a SOC stays effective over the years.
Alongside it, playbooks and a process for case handling, so that an alert becomes a decision and not a ticket.
What belongs in the report at the end
The supervisory view is on the resilience of processes, not on individual findings. A report listing twenty technical weaknesses does not answer the question of whether a realistic attacker could have disrupted a critical function.
So we set out which requirement is covered by which piece of evidence. For institutions of corresponding systemic importance, threat-led testing comes on top; for everyone else the requirement remains to test regularly and in proportion to risk. Not being obliged to test does not mean not being attacked.
What institutions and insurers ask
That depends on systemic importance, payment volume and role. The classification is made by the supervisor. We work out with you what follows from it for your testing programme, whether or not a formal obligation exists.
A penetration test examines a defined scope in depth. A red team pursues an objective and puts detection and response to the test on the way. The question is a different one, so the result is too.
That is a usable result, not a failure. The analysis shows whether the data source was missing, or the use case, or whether the alert was there and got lost in the handling.
Before a supervisory audit, after consolidating or rebuilding the monitoring, when connecting a new service provider with production access, or when reports exist but it is unclear whether the detection would have worked.
