How a TIBER-EU test concludes with the test summary report and attestation
A TIBER-EU test ends when the test manager has approved a test summary report and a remediation plan and the TIBER authority has signed the attestation. Those three documents close the test. The attestation confirms that the test met the framework's core requirements, and under DORA Article 26(7) it is what allows competent authorities to mutually recognize threat-led penetration tests. For an entity that has just finished active red team testing, the closure work is where the test either turns into owned, funded remediation or stalls. Weak closure documents leave findings without an owner, and a finding without a named owner tends to outlive the test that found it.
Closure is hard mainly because many parties feed into it. The 360 degree feedback meeting, organized by the test manager after replay and purple teaming, collects written comments from the control team, the blue team, the threat intelligence provider, the red team testers and the authority on each other and on the process. The test summary report must then cover at least 15 elements, including validated scope, scenarios, attack paths, flags captured, blue team detections, leg-ups, findings with criticality and root causes. Entities should plan one person to reconcile conflicting feedback and confirm that every finding in the red and blue team reports appears in the summary with a consistent criticality rating.
The remediation plan runs on the same eight-week clock as the summary report, so the two should be drafted together. For each shortcoming, the plan must give the proposed measure, its priority, expected completion, a root cause analysis, the staff or functions responsible and the risk of not acting. Confirm early which executives will accept that accountability and whether the remediation budget is already approved, because a plan that assigns work to functions that never agreed to it will not hold. If the test also meets DORA TLPT requirements, check whether your competent authority must receive both documents, since the framework requires this when it is not the TIBER authority. Ask the authority for its approval checklist before drafting begins.
What the test summary report must contain
The test summary report must cover at least 15 elements, and the framework lists them in groups that map to how an assessor checks a test. The report and the remediation plan are both due to the test manager within eight weeks of the test manager's notification that the red and blue team reports have been assessed, so the content below should be ready well before that clock starts.
Scope and scenarios
The report must record the validated scope and the scenarios the test ran. An assessor compares these against the scope specification and the targeted threat intelligence report to confirm the test followed the agreed plan. Check that every critical or important function and flag in the approved scope appears, and that any change made during testing was approved by the test manager and is explained in the report.
Attack paths and flags
The report must show the attack paths the red team followed and which flags it captured. Assessors use this section to see how far an attacker could reach toward the crown jewels, not just which single weaknesses existed. Confirm that each flag is linked to the path that reached it, and that any flag not captured is explained rather than silently omitted.
Blue team detections and leg-ups
This group records what the blue team detected, when, and where the red team needed help to continue. Leg-ups are assistance the control team gave to move the test forward, and they must be shown openly because they change what the result means. Check that detections are described with their timing and that every leg-up is marked so the reader can judge the gaps the test actually exposed.
Findings with criticality
Each finding must carry a criticality rating, so the entity can see which weaknesses need action first. Assessors look for findings that trace back to specific attack paths and flags, not a generic list copied from a scanner. Check that every finding has a clear rating, a reproducible description and a link to the scenario in which it appeared.
Root causes
Each significant finding must be traced to a root cause, such as a process gap, a configuration decision, a missing control or an ownership problem. Root causes matter to the assessor because they decide whether the remediation plan fixes a symptom or the underlying condition. Confirm that root causes name the function responsible, so the remediation plan can assign owners without guesswork.
High-level remediation plan
The test summary report must include a high-level remediation plan that summarizes the detailed plan due at the same time. It gives leadership a view of the main workstreams, their priority and the risks of leaving them open. Check that the summary matches the detailed remediation plan line by line, because the attestation depends on both documents being consistent.
What the remediation plan commits the entity to
The remediation plan is the commitment the entity makes to the test manager after a TIBER-EU test, and it is due within the same eight-week window as the test summary report, counted from the test manager's notification that the red and blue team reports have been assessed. For each shortcoming it must describe the proposed remediation measures, give each measure a priority and an expected completion date, record a root cause analysis, name the staff or functions responsible, and state the risks of not implementing the measures. Those five elements are what the authority reads to decide whether the entity has understood its weaknesses well enough to fix them.
The remediation plan is usually the document most often challenged, for a practical reason: it is where vague intent becomes a dated obligation with a named owner. Reviewers tend to push back on measures that treat symptoms rather than root causes, on completion dates that are not tied to any budget or change process, and on responsibilities assigned to a committee instead of a person or function. Before drafting, the entity should confirm which teams own each affected control, whether funding is approved for the work, and whether any measure depends on a third-party provider whose contract may need to change. Confirm these points with the authority's guidance on the remediation plan, since the detailed expectations are set out there.
Every shortcoming in the plan should trace back to a finding in the test summary report, which in turn traces to the red team and blue team reports. Reviewers check that link in both directions: each finding with a criticality rating should map to at least one measure, and each measure should point to the finding, root cause and detection gap it addresses. A useful internal check is to walk the finding list from the test summary report and confirm that every item either has a remediation entry or a documented reason for acceptance with the risk stated. Teams that build this traceability while the test is still fresh avoid rework when the authority asks why a particular weakness has no owner.
How the test manager and authority review these documents
The test manager is the first reviewer. Once the red and blue team reports have been assessed, the test manager receives the test summary report and the remediation plan for approval within eight weeks of its notification. The check is largely a completeness and traceability review: every required element should be present, and each element should be traceable back to evidence from the testing phase. The test summary report must cover at least 15 elements, including validated scope, scenarios, attack paths, flags captured, blue team detections, leg-ups, findings with criticality, root causes and a high-level remediation plan.
- Element coverage: Each of the 15 required elements is present and labeled so the reviewer can find it without searching.
- Traceability: Findings link to the red team report and blue team report, and flags and attack paths match the scenarios in the test plan.
- Validated scope: The scope in the summary matches the scope specification document that was approved earlier.
- Consistency of criticality: Severity ratings for findings match between the summary and the source reports.
- Root causes and priorities: Each shortcoming has a stated root cause and a remediation priority that the plan can support.
Before submission, confirm with the test manager which template or format it expects, and check that the summary and plan use the same finding identifiers.
The TIBER authority approves both the test summary report and the remediation plan. This is the decision point that moves the test toward closure. Approval also gives the authority the basis to sign the attestation, which records the test dates, functions in scope and those not tested, participating entities and ICT providers, use of internal testers, whether providers met the procurement standards, and the active red team duration in calendar days. The authority reviews substance as well as completeness, so the remediation plan must be realistic about ownership and timing.
- Remediation plan substance: Each shortcoming has measures, a priority, an expected completion, named responsible staff or functions, and a description of the risk of not acting.
- Attestation facts: Dates, functions in and out of scope, and provider details match the procurement and testing records.
- Feedback incorporated: Points raised in the 360 degree feedback meeting are reflected where they affect the documents.
- Procurement evidence: Records show whether providers met the procurement standards, since the attestation records this.
Before submission, ask the authority which items it has previously returned and make sure the attestation facts can be traced to signed records.
When a TIBER test is used to meet DORA TLPT requirements, the test summary report and remediation plan must also go to the entity's competent authority, unless that authority is already the TIBER authority. This copy is a notification and transfer step, and the competent authority uses it in its own supervisory process. The attestation is what supports mutual recognition of threat-led penetration tests between competent authorities under DORA Article 26(7), so the copy should arrive with the approved set of documents rather than in fragments.
- Correct recipient: Confirm whether the entity's competent authority is also the TIBER authority, since that decides whether a separate copy is needed.
- Complete set: Send the approved summary report, remediation plan and signed attestation together.
- Version control: Send the version the TIBER authority approved, and keep a record of the transmission date.
- Sensitivity handling: Apply the same restricted handling to the copy that applies to the original documents.
- Consistent references: Use the same test identifiers and dates as the attestation.
Before sending, ask the TIBER authority and the competent authority which channel and format each expects.
How an assessor tests the closure package
This table compares the checks an assessor runs on the test summary report, remediation plan and attestation, with the evidence each check needs and the gaps that appear most often. Read each row as a question the authority will ask before approving the closure package and signing the attestation. The main takeaway is that the documents must trace cleanly back to the red and blue team reports, because most rejections come from gaps in that chain rather than from missing sections.
| Check | Evidence requested | Common findings |
|---|---|---|
| Completeness against mandatory elements | Test summary report mapped to each of the 15 or more required elements, including validated scope, scenarios, attack paths, flags captured, blue team detections, leg-ups and findings with criticality | Sections present but thin, such as leg-ups described without the step that enabled them or flags listed without the path to reach them |
| Traceability from findings to remediation | Each finding linked to its root cause, the remediation measure, the priority, the responsible function and the red or blue team report reference | Remediation items that do not map back to a specific finding, or findings with no owner or no root cause analysis |
| Remediation plan content | Per shortcoming: proposed measures, priority, expected completion date, root cause analysis, responsible staff or functions, and the risk of not acting | Expected completion dates missing, risk of non-implementation omitted, or responsibilities assigned to a team name with no accountable person |
| Timing against the eight-week rule | Dated record of the test manager's notification that the red and blue team reports were assessed, and the submission date of both documents | Submission after the eight-week window without a documented agreement, or no record of when the notification was received |
| 360 degree feedback and its record | Minutes of the feedback meeting and written feedback from each party, with a note on any anonymous sharing with the Knowledge Centre | Feedback meeting held after approval, or written input from some parties missing |
| Attestation content: dates, scope and exclusions | Test dates, functions in scope, functions not tested with reasons, participating entities and ICT providers | Functions excluded without a documented rationale, or ICT providers named in the report that do not match the procurement records |
| Internal testers and procurement standards | Statement on whether internal testers were used, and evidence that external providers met the procurement standards | Internal testers used without a clear statement of their role, or procurement evidence that does not match the providers who actually tested |
| Active red team duration in calendar days | Start and end dates of active testing that produce the calendar-day count in the attestation | Duration counted from the wrong start point, or a count that conflicts with dates recorded in the red team test report |
Steps to close a TIBER-EU test cleanly
The closing sequence turns the red and blue team findings into a documented record the authority can approve. Each step produces a named output, from the 360 degree feedback notes to the signed attestation, and the entity keeps control of its own conclusions throughout.
Hold the 360 degree feedback meeting
The test manager organizes this meeting after replay and purple teaming and before the test summary report and remediation plan are approved. Every party, including the control team, blue team, threat intelligence provider and red team testers, gives written feedback on the other parties and on the process. Prepare by collecting your own team's observations in advance, so the input covers what worked in detection and response as well as what slowed the test down. Output: written feedback from each party, which the test manager may share anonymously with the TIBER-EU Knowledge Centre.
Draft the test summary report
Draft the test summary report from the assessed red and blue team reports, the replay and purple teaming outputs, and the feedback gathered at the 360 degree meeting. The report must cover at least 15 elements, including the validated scope, scenarios, attack paths, flags captured, blue team detections, leg-ups, findings with criticality, root causes and a high-level remediation plan. Assign one owner for each section and a reviewer who checks every finding against its source report. Output: a draft that traces each finding to red or blue team evidence, with a checklist confirming all required elements are present.
Build the remediation plan with owners
For each shortcoming, record the proposed remediation measure, its priority, its expected completion, the root cause analysis and the staff or functions responsible. Add the risk of not implementing each measure, which the framework requires, so the accepting executives can see the consequences of deferral. Name an accountable owner for each measure and confirm that the owner has agreed to the target date before it goes into the document. Output: a plan in which every shortcoming has a priority, a dated target, a named owner and a stated risk.
Obtain internal sign-off on both documents
Confirm which committee or executive your internal governance requires to approve a threat-led penetration test outcome, and schedule that review before the submission window closes. Check the drafts against the source reports and the evidence trail, correcting any statement the evidence does not support. Record the approvers' names, roles and dates. Output: a signed internal approval record and final versions of both documents, with a change log showing what was revised during review.
Submit both documents to the test manager
Send the test summary report and the remediation plan to the test manager within the eight-week window that runs from the test manager's notification that the red and blue team reports have been assessed. Where the TIBER-EU test is used to meet DORA TLPT requirements, also send both documents to your competent authority if it is not the TIBER authority. Handle both documents as highly sensitive and confirm the transfer method with the test manager beforehand. Output: a transmittal record showing the submission date, recipients and document versions.
Answer authority questions on the drafts
The test manager and authority may question findings, scope statements or remediation dates before approval. Assign one coordinator to log each question, route it to the owner of the relevant section, and return a written answer with any revised text tracked. Change a finding only where new evidence supports the change, and record the reason. Output: a question log in which every query is closed, plus a version history showing how each document changed after submission.
Receive and file the signed attestation
After approving both documents, the TIBER authority signs the attestation, which concludes the test. Check that it records the test dates, the functions in scope and those not tested, the participating entities and ICT providers, the use of internal testers, whether providers met the procurement standards, and the active red team duration in calendar days. Under DORA Article 26(7), the attestation supports mutual recognition of the test between competent authorities. An implementation partner can assemble the evidence file for this check, but only the authority signs the attestation. Output: the signed attestation filed with the complete test evidence.
Evidence that supports the attestation
The attestation is signed only after the authority has approved the test summary report and remediation plan, and it records facts drawn from the rest of the test file. The cards below are the records an assessor or authority will expect to see, and the ones the tested entity should keep current after the test concludes.
Approved test summary report
The test summary report is the document the authority approves before it signs the attestation. It must cover at least 15 elements, including validated scope, scenarios, attack paths, flags captured, blue team detections, leg-ups, findings with criticality and root causes. Check that every finding in the report links back to a red team test report entry and that the validated scope matches the scope specification document, not the scope as first planned.
Approved remediation plan
The remediation plan records each shortcoming, the proposed measures with priority and expected completion, a root cause analysis, the staff or functions responsible, and the risks of not implementing each measure. Confirm that every owner named in the plan has accepted the role in writing. Because the plan is approved with the summary report, changes after approval should be recorded as a documented revision rather than edited silently.
360 degree feedback records
The 360 degree feedback meeting gives every party a chance to give written feedback on each other and on the process. Keep the signed or dated written feedback, the meeting minutes and the record of any decision to share feedback anonymously with the TIBER-EU Knowledge Centre. These records show the authority that lessons were captured, and they feed the next test's preparation and procurement.
Traceability register for flags and findings
A traceability register links each flag and finding to its remediation ticket, owner, status and verification date. It shows the authority that a finding in the summary report was actually tracked to closure rather than left in a document. Maintain it in a system the entity controls, export it with the approved plan, and reconcile it against open tickets each month until every measure is closed or formally accepted as a risk.
Procurement evidence for providers
The attestation records whether the threat intelligence provider and red team testers met the procurement standards. Keep the signed contracts, the due diligence file, the evidence of each provider's qualifications and any written waivers. Confirm with the authority which procurement guidance applies in your jurisdiction, since the ECB publishes separate guidance on service provider procurement.
Active testing duration records
The attestation states the active red team duration in calendar days, so the entity must keep the dated start and end records for active testing, along with the log of any pauses or extensions approved by the control team. Store these alongside the red team test report so the stated duration can be checked against the source records without reconstruction from memory.
What closing a TIBER-EU test costs in money and effort
The table compares who carries each cost when a TIBER-EU test closes, from drafting the test summary report to funding remediation. Read it as a checklist for a quote: each row names the party paid or exposed, whether the cost is one-time or recurring, and what moves it up or down. No figures are given because none were supplied for this phase.
| Cost component | Who carries it | One-time or recurring, and drivers |
|---|---|---|
| Internal staff time on drafting the test summary report and remediation plan | The tested entity (control team and test management) | One-time per test. Drivers: number of scenarios, flags and findings, and how much blue team detail must be documented across the 15 required elements. |
| Internal ownership of remediation measures | The tested entity (function owners named in the remediation plan) | Recurring until closed. Drivers: number of root causes, priority ranking, and whether fixes need changes to ICT systems or third-party contracts. |
| Red team and threat intelligence provider effort on report input | The external providers, under their procurement contracts | One-time per test, often defined in the contract. Ask whether input to the summary report and clarifications after approval are in scope. |
| External reviewer or consultant fees | The tested entity, if it engages one for drafting or quality review | One-time, optional. Drivers: team capacity, familiarity with TIBER-EU documents, and the number of review rounds. Ask for the review scope in writing. |
| Findings tracking tooling | The tested entity (licenses, hosting or open-source deployment and administration) | Recurring for licenses or hosting, one-time for setup. Open-source options exist, such as DefectDojo, which imports findings from many tool formats. Confirm integration effort in your environment. |
| Remediation work that follows the plan | The tested entity, plus any ICT providers it relies on | Largest and longest cost, often recurring across budget cycles. Drivers: the severity of findings, dependence on legacy systems, and contract change requests with ICT providers. |
| Authority review and attestation handling | The tested entity (preparing responses to authority comments) | One-time per test. Drivers: completeness of the documents on first submission and whether the authority requests additional evidence. Confirm the authority's process and deadlines first. |
Who writes, owns and attests each closure document
The tested entity owns its closure documents. Its management is accountable for the remediation plan, which must describe each shortcoming, the proposed measures with priority and expected completion, the root cause analysis, the staff or functions responsible, and the risks of not acting. Those owners must be named inside the entity, because the plan commits the organization to work it will carry out after the test ends.
- Remediation owners: Assign a named function or senior manager to each shortcoming, not only to the security team.
- Root cause analysis: The entity's own engineers and process owners should confirm causes, since they know the environment best.
- Feedback input: The control team and blue team contribute written feedback at the 360 degree meeting on each other and on the process.
- Management acceptance: Senior management should review the risks of not implementing measures before the plan goes to the test manager.
- Evidence of progress: Keep records of how each measure is delivered, since later assessments will look at them.
Before approval, confirm that every shortcoming in the test summary report has an owner and a completion expectation in the remediation plan.
An implementation partner can help the entity prepare the evidence and drafting support behind the closure documents. Typical work includes organizing the blue team evidence, reconciling findings with systems and configurations, and preparing draft tables for the remediation plan. The partner does not own the plan, does not decide priorities on the entity's behalf and does not sign the attestation.
- Evidence preparation: Gather configuration records, logs and change tickets that show how a finding was fixed or why it remains open.
- Drafting support: Prepare first drafts of remediation tables for the entity's owners to review, correct and approve.
- Traceability: Maintain a register linking each finding to its owner, measure and status.
- Technical validation: Re-test remediated items where the entity asks for it, and record results without reissuing the authority's reports.
- Scope limits: Work under a written fixed scope agreed in advance, with the entity retaining decision rights.
Ask any partner to state in writing which closure documents it will touch, and confirm that it will not present its drafts as the entity's signed commitments or as authority findings.
The TIBER authority, through the test manager, assesses the red and blue team reports, organizes the 360 degree feedback meeting, approves the test summary report and remediation plan, and signs the attestation. The attestation records the test dates, functions in scope and not tested, participating entities and ICT providers, use of internal testers, whether providers met procurement standards, and the active red team duration in calendar days. Under DORA Article 26(7), that attestation supports mutual recognition between competent authorities.
- Assessment: The test manager's assessment of the red and blue team reports starts the eight week clock for both closure documents.
- Approval: Approval of the test summary report and remediation plan is the authority's decision, not the entity's or a partner's.
- Attestation: Only the authority signs, and it signs only after approving both documents.
- Knowledge Centre sharing: The test manager may share 360 degree feedback anonymously with the TIBER-EU Knowledge Centre.
- Regulator copy: Where the test meets DORA TLPT, the summary and plan also go to the entity's competent authority if that authority is not the TIBER authority.
Confirm with your authority which documents it expects in which format, and whether its national implementation adds requirements.
Open-source tools that track findings and remediation evidence
This table compares three open-source tools that can hold the findings, scan results and compliance mapping behind a TIBER-EU test summary report and remediation plan. Read each row against the closure evidence your test manager expects, then confirm the reporting format and document handling with them before you choose a tool.
| Tool and license | Traceability role | Evidence it produces | What to confirm |
|---|---|---|---|
| DefectDojo (BSD-3-Clause) | Imports and reimports findings from many security tool report formats and deduplicates them using per-tool hashcode fields | A consolidated findings register that links each red team finding to its source report, status history and remediation owner | Whether the test manager accepts the export format for the test summary report and how highly sensitive red team material is stored and access-controlled |
| Greenbone Community Edition (AGPL-3.0-or-later) | The gvmd service stores vulnerability scan results in PostgreSQL, manages users and permissions, and schedules scan tasks | Dated scan results and user activity that show which vulnerabilities existed when remediation work began and when it was verified | Whether scan coverage matches the validated scope of the test and how AGPL obligations apply if the tool is modified and offered to users |
| CISO Assistant (AGPL-3.0-only) | Runs audits and compliance assessments against more than 200 frameworks, including DORA, with automatic mapping between frameworks | A DORA-aligned assessment record that ties remediation measures, owners and risks to the framework requirements the entity reports against | Whether the DORA mapping matches the entity's competent authority expectations and whether the test manager or authority will accept it as supporting evidence rather than a required format |
| Shared closure use | Holds the inputs for the test summary report and remediation plan, which are due within eight weeks of the test manager's notification | Traceable links from each shortcoming to its root cause, remediation measure, priority, expected completion date and responsible function | The reporting fit with the test manager, the required fields for the 15 test summary report elements and the approval workflow before any tool is used for final submission |
Where closure packages usually fall short
Why do findings without criticality cause problems in the test summary report?
Findings without a stated criticality leave the authority unable to judge which weaknesses matter most, and the test summary report is expected to show findings with criticality. Reviewers then send the document back, which uses up part of the eight-week window. The fix is to have the red team test report's criticality rating carried into the summary as a fixed field for every finding, with the rating basis written down. Ask the red team provider to show how each rating was reached, so the entity can defend it in the approval discussion. Root causes should be linked to the same finding IDs so the criticality and cause can be read together.
What goes wrong when the remediation plan lacks root cause analysis?
A remediation plan that lists fixes without root causes tends to treat symptoms, so the same weakness can return in the next test. The framework requires each shortcoming to be paired with a root cause analysis, and the plan should show which cause each measure addresses. Build a short table with one row per shortcoming: the observed weakness, the root cause, the measure, its priority, and its expected completion date. Where several findings share one cause, group them under that cause so the plan does not repeat work. Review the table with the control team before submission so the cause statements match what the blue team observed.
Should remediation owners be named by role or by person?
Owners should be named by function and by accountable person, because a function alone does not show who must act when the deadline approaches. Many plans list a team such as the security operations function and stop there, which leaves no one to answer for delays. Record a named individual as the accountable owner, with the function that delivers the work beside the name. Confirm that each named person has agreed to the role and has the authority to change the systems or processes involved. Update the owner field when staff change, since an out-of-date name is a common reason for a stale plan.
Why must the risks of not implementing each measure be stated?
The remediation plan must describe the risk of not implementing each proposed measure, and plans that omit this give the authority no basis to judge whether the proposed priority is right. Without it, a low-priority measure may look as urgent as a critical one. For each measure, write the specific exposure that remains if the measure is not done, such as which attack path stays open or which detection gap persists. Keep the statement tied to the tested scenario and the flags captured, so it reads as a consequence of the test rather than a generic warning. Where the entity accepts a risk instead of fixing it, record that decision and who approved it.
How should 360 degree feedback be recorded so it is not lost?
The 360 degree feedback meeting is required before the test summary report and remediation plan are approved, and written feedback from each party should be kept on file. Teams often hold the meeting, record only verbal notes, and then fail to show that every party contributed. Ask the test manager to circulate a written feedback form before the meeting, collect each party's submissions in writing, and file them with the closure documents. Note which feedback led to a change in the report or process. Record whether the entity agrees to share the feedback anonymously with the TIBER-EU Knowledge Centre, since that choice belongs to the test manager and should be documented.
When should attestation data be collected to avoid last-minute gaps?
Attestation data should be collected during the testing and closure phases, not at the end, because several required items depend on records made much earlier. The attestation records test dates, functions in scope and those not tested, participating entities and ICT providers, use of internal testers, whether providers met the procurement standards, and the active red team duration in calendar days. Start a register at procurement and update it as each phase closes. Ask the test manager to confirm the exact fields the authority expects, since national implementations may add items. Reconcile the active test duration against the testing logs before submission, so the figure in the attestation matches the record.
Can the entity's internal team prepare the closure package without outside help?
An entity can prepare its own closure package, but the work needs people who know the controls, the test evidence and the framework's document requirements. Internal teams usually own the remediation measures and their owners, while the red and blue team reports supply the findings and detections. An implementation partner such as DeployOpen can help prepare systems and evidence, such as a findings register and tracking tools, but it does not approve documents or sign the attestation. The authority and the independent process owners remain responsible for those steps. Ask any outside party to confirm in writing which deliverables it prepares and which the entity owns.
Which tools can track findings and remediation status through closure?
Tools such as DefectDojo can hold findings from several sources, deduplicate them and track their status, which helps keep the summary, remediation plan and attestation consistent. DefectDojo's documentation lists supported tool formats and deduplication through per-tool hashcode fields, which is useful when findings arrive from multiple test activities. Check that the imported findings carry criticality, root cause and owner fields, since a tool does not supply these by default. Confirm the licence terms and the import formats for your own report files before relying on the tool for closure evidence. You can review supported formats in the DefectDojo supported tools documentation.
How DeployOpen prepares closure evidence for TIBER-EU tests
DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure. For the closure phase, we prepare the systems, records and evidence that support the test summary report, remediation plan and attestation, while the organization owns its controls and the TIBER authority approves and attests the outcome.
How we scope
- Our written scope lists which closure documents and evidence sets we prepare, agreed before work starts.
- Scope names the systems that hold findings, detections and remediation records for the test.
- Engagements are fixed-scope, so deliverables and timelines for closure are confirmed in writing first.
- Confirm with the test manager which contents the summary report must cover before we begin.
How we build
- We configure self-hosted tools to consolidate red and blue team findings in one tracked register.
- Deduplicated findings are linked to root causes, owners and criticality so the summary report draws on one source.
- Remediation tracking records priority, expected completion and responsible functions for each shortcoming.
- Access to closure records is restricted, since these documents are handled as highly sensitive material.
How we hand over
- We deliver an evidence pack mapping each required summary report element to its source record.
- Remediation plan drafts document each measure, its priority, owner and the risk of not implementing it.
- Documentation covers how records were produced, so the organization and its auditors can trace every claim.
- The authority reviews and signs the attestation; DeployOpen does not issue or approve it.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the closure phase.
- We help teams track remediation progress against the dates agreed with the test manager.
- Ask us to confirm platform upgrade and backup procedures that keep closure records available for later reviews.
- Retainers can cover retesting of remediated findings within an agreed scope.
