Custom app development for the blue team during a TLPT
In a threat-led penetration test under DORA, the blue team does not know a test is taking place. That is the design: the defence must respond as it would to a real attack. Only afterwards does the team learn what was going on, and then it must show, for each attack step, what it noticed and when.
What is asked of you afterwards
The technical regulatory standard under DORA, Delegated Regulation (EU) 2025/1190, describes the blue team as the people who defend the systems and who are not informed of the TLPT. They carry on with their normal work: the security operations centre, the service desk, incident management. The control team lead only informs them after the active red team testing phase ends, and that phase lasts at least twelve weeks.
Then comes the report. Within four weeks of that end, the testers deliver their red team test report, and no later than ten weeks after the same end, the blue team delivers its own. Annex VI sets out what it must contain: for each attack step, the attack actions detected with their log entries, an assessment of the testers' findings, the evidence gathered, a root cause analysis, lessons learned and topics for purple teaming.
That report cannot be assembled after the fact. The detections lie weeks back, spread across services and systems, and the question is not only whether something was noticed but when, by whom, and what followed. What was not recorded at the time is not there later. The process and the file around it are described on our page about software for the TLPT process.
How we build this
The app must already be in use before anyone knows a test is running. Something rolled out only after the notification gives the test away and starts with no history.
Observations, triage and escalation are part of the normal work of the security centre, and the app makes no exception for them.
When a signal came in, when an analyst picked it up and when it was escalated. Those three moments carry the reconstruction.
Annex VI asks for the log entries behind each detection. A reference to a system that has since been cleaned up is not evidence.
Afterwards, you lay your timeline alongside the testers' attack paths. We build that comparison rather than leaving you to do it in a spreadsheet.
What the app does in practice
The observation with its timestamp carries the whole. What else you record depends on how your detection is set up and who owns it.
Observation at the moment itself
What was seen, in which system and what drew attention to it. Recorded during the shift, not from memory weeks later.
The timeline from signal to response
Intake, pick-up, assessment, escalation and closure, with time and person. The blue team's report rests on that sequence.
Keeping the log entry alongside
From your SIEM or detection platform, linked to the observation and retained with the file. Annex VI explicitly requires this.
Handover between services
A signal that arises overnight and is handled during the day keeps its history. Otherwise the response time you must demonstrate disappears.
The analyst's judgement alongside
Why something was dismissed as noise or, conversely, escalated. In the replay, that judgement is more interesting than the outcome.
Shielding what is sensitive
Test managers can ask for a report without sensitive information. That only works if the source has already flagged what is sensitive.
Who we build for
Where detection sits varies by institution. Four situations.
An in-house security operations centre
Analysts on duty rotas, with existing tooling and procedures. Here the aim is to record alongside those systems, not instead of them. See also software for the financial sector.
Detection by an external party
Your detection is outsourced and the provider reports in its own way. For Annex VI you need those observations in your own timeline, with its timestamps.
Groups sharing ICT systems
In a joint test, the instruction reaches several entities that use the same intragroup provider. Observations then need to stay separable per entity.
Processes that must not go down
If the test is discovered, the control team must be able to contain the escalation. That only works if it is visible where a report stands.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
What you measure and what you call it differs per detection platform. The content of Annex VI is fixed, the route to it is not, so that route should be configurable.
Why Appfront
A timestamp cannot be reconstructed
We record the moment something was noticed, not the moment someone remembers it. In the replay with the testers, the conversation is about that difference.
The report grows out of the service
We build the recording so that Annex VI becomes an export of what is already there. Anyone who only starts collecting after the disclosure will deliver a reconstruction.
The app does not reveal the test
The blue team must not know that a TLPT is running. We therefore do not build a test mode and show no marking in the app; the control team works in a separate section.
We do not test and we do not defend
You hire the red team separately and the defence is your job. We build the recording that lets you show afterwards what was noticed.
Security and privacy
Observations from your defence show what you do and do not see. That is as useful to an attacker as to you, and the RTS counts this as sensitive information: test managers can ask for a report from which it is missing. We set that marking at the source, per observation, so such a version is not a cut-and-paste job afterwards.
The reliability of the timeline is the whole point here. A timestamp that can be adjusted later makes the comparison with the testers' attack paths worthless. We record observations tamper-proof with timestamp and person, and show any correction visibly alongside the original entry. Where that recording runs is a separate consideration; for this sector we also build on a sovereign cloud. How we handle security ourselves is set out in our information security policy; reports from outside come in through our CVD policy.
Frequently asked questions about the blue team in a TLPT
Yes, that is how the RTS sets it out. Information about the test stays with the control team, the management body, the testers, the threat intelligence provider and the authority. The blue team only learns of it after the active phase.
Annex VI requires, for each attack step in the red team test report, the attack actions detected and their log entries, plus an assessment of the testers' findings, the evidence gathered, a root cause analysis and topics for purple teaming.
At least twelve weeks, according to the RTS, and longer in proportion to the scope and complexity of the entities involved. The control team, the testers and the test managers agree when that phase ends.
A joint exercise between the testers and the blue team. No later than ten weeks after the active phase ends, a replay of the offensive and defensive actions follows, with purple teaming on what both sides saw. Since the update to TIBER-EU, this step is mandatory.
The RTS sets out the procedure: the control team is informed of every discovery and, where necessary, steps in to halt escalation. It then proposes measures to the test managers so the test can continue and remain confidential. Your records must show where a report was left. Recognition among staff falls under an awareness platform.
Because the observation arises on the operational floor, not in a file. A ticket records that something has been dealt with; Annex VI asks what was detected, when and how. We build that layer alongside your existing systems.
The latter concerns a product you have examined; here it is a regulated testing regime with a supervisor present. For the former there is app security testing and the ICT security assessment; for DORA as a whole there is DORA compliance software.
That depends on the number of teams, where detection sits and which integrations you want. The recording is usually the first thing to become useful and immediately starts building history. We will give you a substantiated estimate after the discovery phase.
Can you demonstrate what you saw at the time?
Take an incident from last quarter and find out when the first signal came in and who picked it up. If you cannot do that now, you will not manage it after a TLPT either. We build this separately and within a broader app development project.