Who may run a TLPT under DORA Article 27
Article 27 sets the conditions that testers must meet before a financial entity can rely on their work for a threat-led penetration test under DORA. If your entity must run a TLPT, whether you plan to use internal staff or external firms, the first question is not which tool or method the team will use but whether each tester on the team qualifies. The Article sets out who may test, and the answer depends on the suitability and reputation of the provider, specific expertise in threat intelligence, penetration testing and red team testing, an accreditation or formal code of conduct, independent assurance over the tester's TLPT risk management, and professional indemnity insurance. Those conditions apply to the people and firms doing the work, not only to the organization that commissions it.
The risk behind these conditions is practical. A tester without the right skills can produce a weak or misleading picture of your defenses, and a tester with a conflict of interest may shape findings to suit a relationship or a commercial interest. Poor handling of live attack techniques or sensitive results can also create exposure for the entity itself. The entity still owns the test, sets its scope and carries the regulatory responsibility, but the tester's qualification is a separate question that must be proven. Keep those two roles apart in your planning so that a clean contract does not hide an unqualified team.
What makes this hard is evidence. Expertise, independence and insurance must be shown for every person who takes part, including threat intelligence analysts, red team members and anyone who handles results, not only for the firm's brand or lead. Ask each provider for named roles, certifications or accreditation details, codes of conduct they adhere to, the independent assurance report covering their TLPT risk management, and proof of current professional indemnity cover. Confirm with your competent authority how the Article applies to your entity, and confirm the current wording of the standards on the EUR-Lex copy of DORA before you finalize a tender.
Which testers and engagements fall under the Article 27 conditions
Article 27 applies differently depending on who performs the test, whether the testers sit inside or outside the entity, and which part of the threat-led exercise they cover. The cards below set out the decisions that change the work, so that the entity can confirm early which conditions bind it.
External testing providers
An external provider must meet the full set of Article 27(1) conditions: high suitability and reputability, specific expertise, certification by an accreditation body or adherence to a formal code of conduct, independent assurance over its TLPT risk management, and professional indemnity insurance. Ask the provider for evidence of each condition before contracting, not after the test has started.
Internal testing teams
An entity may use internal testers only if the competent authority or designated TLPT authority approves their use. The entity must also show sufficient dedicated resources and no conflicts of interest. Internal teams are a scoping decision that needs regulator sign-off, so confirm approval status before planning the exercise around in-house staff.
Intra-group providers count as internal
Under the TLPT RTS, testers employed by an ICT intra-group service provider count as internal, not external. A group that routes testing through a sister company therefore still has to meet the internal team rules, including the test lead and member requirements and the approval condition. Map each tester to their employer before classifying the team.
Threat intelligence providers
The threat intelligence provider must be external to the entity, even where the testers themselves are internal. This separation keeps threat analysis independent of the team that will attack the systems. Confirm that the intelligence provider is not part of the entity's group or staff before accepting its scenarios.
Red team testers
Red team testers carry the attack execution and are judged on their own expertise in penetration and red team testing. Ask whether the provider's red team has the required lead and tester experience and the reference count set out in the TLPT RTS. Separate these checks from those for the threat intelligence provider, because the two roles are assessed on different criteria.
Mandatory external testing for significant institutions
Under Article 26(8), entities that use internal testers must contract external testers every three tests. Credit institutions classified as significant may use only external testers. Entities that cannot predict their classification should confirm it with their competent authority before designing the internal team model.
How an assessor tests tester qualifications
This table shows how a competent authority or reviewer tests each Article 27 condition, what evidence it asks for, and where submissions usually fail. Read it as a checklist you can run against your own tester file before the authority or your auditor asks for it. The main takeaway is that every condition needs dated, verifiable proof, not a statement that the tester is qualified.
| Condition | What the reviewer checks | Evidence requested | Common findings |
|---|---|---|---|
| Suitability and reputability (Art. 27(1)) | Whether the firm and its named testers have a track record and standing that a supervisor would accept for critical testing | Company profile, client references, background checks on named testers, any regulatory or litigation history disclosed | Testers named without background checks, references not verifiable, unexplained gaps in history |
| Threat intelligence expertise | Whether the team has skills in threat intelligence and the Delegated Regulation (EU) 2025/1190 staffing profile for that team | CVs with dated roles, certifications held, team org chart, lead manager experience records | CVs without dates, experience claimed but not tied to threat intelligence work, team lead below the required experience |
| Penetration testing and red team expertise | Whether the red team lead and testers have the experience the TLPT RTS requires for red teaming | Named red team roster, years of experience per person, sample engagement records, reference letters | Experience counted from junior roles, testers listed without a lead, experience that cannot be reconciled with CVs |
| Accreditation or codes of conduct (Art. 27(1)) | Whether each tester is certified by an accreditation body in a member state or follows a formal code of conduct or ethical framework | Accreditation certificates with issuer and validity dates, signed adherence statement to a named code, verification check | Expired certificates, certificates from bodies that cannot be confirmed, codes cited without evidence of adherence |
| Independent assurance or audit report (Art. 27(1)) | Whether an independent party has examined the tester's risk management for TLPT work and reported on it | Recent independent assurance or audit report covering TLPT risk management, scope statement, date of the report | Report older than the engagement, report covering general security rather than TLPT risk management, no independence statement |
| Professional indemnity insurance (Art. 27(1)) | Whether the tester holds current cover that fits the scope and risk of the test | Insurance certificate with insurer, cover amount, policy period and insured activities | Policy expired before the test date, cover does not name testing activities, certificate unsigned or unverifiable |
| Internal testers: approval (Art. 27(2)) | Whether the competent or designated TLPT authority approved the use of internal testers | Written approval from the authority, date and scope of approval, named testers covered | Internal testers used without approval on file, approval scope narrower than the actual test |
| Internal testers: dedicated resources and conflicts (Art. 27(2)) | Whether testers have sufficient dedicated time and no conflicts of interest, and whether the threat intelligence provider is external | Resource allocation plan, signed conflict-of-interest declarations, reporting lines, contract with external threat intelligence provider | Testers also running production operations, no conflict declarations on file, threat intelligence sourced internally |
Steps to qualify testers before a TLPT starts
This sequence turns the Article 27 conditions into a documented tester decision that the entity can defend to its competent authority before any threat-led test begins. Each step produces a record that feeds the next, so the final approval rests on evidence rather than assumptions.
Define the tester model
Decide whether the threat-led test will use external testers, internal testers with competent authority approval, or a mixed team. The entity's management, usually with its TLPT authority in view, records the choice and the reasons for it. Internal use requires prior approval under Article 27(2), and credit institutions classified as significant may use only external testers, so this check comes first. The output is a signed tester model decision that names every tester role: threat intelligence provider, red team lead, and any internal test lead or team members.
Verify each tester's credentials against Article 27
For each provider or internal candidate, collect evidence of suitability and reputability, specific expertise in threat intelligence, penetration testing and red team testing, and any accreditation or formal code of conduct or ethical framework the tester adheres to. Compare the evidence against the minimums in the TLPT RTS, including the experience of the team leads and members and the number of references the provider must give. The output is a credential file per tester with a pass or fail note against each condition, and open items sent back to the provider.
Confirm internal team composition and independence
If internal testers are part of the model, check that the internal testing team has a test lead and the minimum number of other members required by the TLPT RTS, and that each person has been employed by the entity or an ICT intra-group provider for the required preceding period. Confirm that the team has the dedicated resources it needs and that no conflicts of interest exist. The output is an internal team roster with employment dates, reporting lines and a signed conflict-of-interest declaration for each member.
Obtain assurance and insurance evidence from providers
Request each external provider's independent assurance or audit report covering its TLPT risk management, along with proof of professional indemnity insurance. Review the scope of the assurance report to confirm it covers the TLPT activities being bought, not only general business operations, and check the insurance cover and its validity dates. The output is a dated assurance and insurance file for each provider, with gaps logged and a decision on whether the provider may proceed.
Set contract terms for results handling
Draft the contract so that it sets out how TLPT results are generated, stored, shared and destroyed, and makes clear that processing of the data across its lifecycle does not create risk for the entity, as Article 27(3) requires. Include confidentiality, security controls on the testing environment, subcontracting limits, and exit or return-of-data terms. Legal and security owners sign off the clauses. The output is an executed or near-final contract with a data handling annex that the entity can show to its competent authority.
Record conflict-of-interest and approval decisions
Bring the credential files, internal roster, assurance evidence and contract terms to a single approval point, which records the decision on each tester and the reasons behind it. Where internal testers are used, the record must show the competent authority or designated TLPT authority approval and confirm that the threat intelligence provider is external to the entity. The output is a tester approval register with dates, decision owners and any conditions attached, ready for regulatory review.
Confirm the register is ready before test start
Before the test begins, check that every approval in the register is current, that insurance and assurance evidence has not lapsed, and that any changes to team members since the decision have been re-assessed. Keep the register under version control so that any replacement tester goes through the same steps. The output is a release confirmation that authorizes the TLPT to start with a named, verified tester set.
What the TLPT RTS adds for team size and experience
Article 27 sets the qualities a tester must have, but the TLPT RTS turns some of them into hard numbers. Under Article 7 of Delegated Regulation (EU) 2025/1190, a threat intelligence team must be led by a manager with at least 5 years' experience, with at least one further member who has 2 years. A red team follows the same pattern for its lead, but needs at least two testers with 2 years each. Providers must also show at least three references for threat intelligence work and at least five references for testers. Before you shortlist a provider, ask for the CVs of the named lead and team members, check the dates against these thresholds, and confirm that the references cover threat intelligence and red team work separately.
For internal testers, Article 15 of the same regulation requires a testing team with a test lead and at least two other members. Every member must have been employed by the entity, or by an ICT intra-group provider, for the preceding 12 months. Article 27(2) adds that the competent authority or designated TLPT authority must approve the use of internal testers, verify that enough dedicated resources exist, and confirm there are no conflicts of interest. Conflicts matter here because the people running the test often work on the systems being attacked, operate the controls being measured, or report into the same managers. Document how each conflict was assessed before you ask for approval.
Article 26(8) limits how often internal testers can be used. An entity that uses internal testers must contract external testers every three tests, and credit institutions classified as significant may use only external testers. Plan the sequence of tests in your multi-year programme so that external providers are engaged on the required cycle, and budget for them as a recurring cost rather than an exception. Confirm with your competent authority how it counts tests and whether an intra-group provider's staff are treated as internal for this purpose.
Evidence that shows tester qualification is met
Article 27 is tested through a file for each tester or provider, not through a single certificate. The cards below cover the records an assessor will ask for, who holds each one, and how to keep them accurate between tests so the file reflects the team that actually runs the next TLPT.
Tester CVs and role verification
Keep a dated CV for every tester and team leader, with each claimed year of penetration testing, red team and threat intelligence work tied to a named role. Verification means checking employment and role records against the CV, not accepting the CV alone. Article 27(1) requires specific expertise in these three areas, and the TLPT RTS sets experience minimums for the team lead and members, so confirm each person against those minimums, not against general seniority.
Accreditation certificates or codes of conduct
Article 27(1) accepts either an accreditation certificate issued by an accreditation body in a member state or formal adherence to a code of conduct or ethical framework. Record which route each provider uses, the issuing body, the scope of the certificate, its validity dates and the date you last confirmed it is still current. A signed adherence statement without a named framework is weak evidence, so ask providers to name the framework and show their adherence.
Independent assurance and audit reports
Where a provider relies on independent assurance or an audit report on its TLPT risk management, file the report itself, the issuing auditor, the period it covers and the scope. Check whether the report covers the risk management processes used for your engagement. An old report covering a different service line does not show the current team or method is controlled. Only independent auditors issue these reports, so the entity should request them from the provider rather than asking the implementation partner to produce one.
Professional indemnity insurance certificates
Hold a current certificate of professional indemnity insurance for each external provider, showing the insurer, the cover limit, the policy period and the insured entity. Check that the insured entity is the contracting firm and not a parent or a sister company whose cover may not apply to the engagement. Calendar the renewal date so a lapse is caught before the next test starts rather than discovered during supervision.
Reference letters and track record
Article 7 of the TLPT RTS requires providers to supply a minimum number of references, three for threat intelligence providers and five for testers. Store each reference with the client type, the year, the scope category and a contact the entity can verify. References should show work of comparable type and scale, and the file should note any reference the entity could not verify. Ask providers to confirm that references are not reused across unrelated engagements without consent.
Internal tester employment and approval records
For internal testing, keep employment records showing that each tester, including the test lead, was employed by the entity or an ICT intra-group provider for the preceding 12 months. Add the competent authority or designated TLPT authority approval, the record of verified dedicated resources, and the conflict-of-interest declarations. Article 15 of the TLPT RTS sets the team structure, and Article 26(8) limits how often internal testers may be used before an external test is required, so track each internal test against that cycle.
Conflict-of-interest and independence declarations
Collect a signed declaration from every tester and provider, covering prior work on the same systems, ownership links to the entity, and any role in building or operating the systems under test. Article 27(2) requires the absence of conflicts of interest for internal testers, and the same concern applies to external firms. Renew declarations at the start of each engagement, because a team member who moved to another client or a related vendor since the last test may now have a conflict.
Signed contract clauses on results handling
Article 27(3) requires contracts with external testers to ensure sound management of TLPT results and that processing of the data, from generation to destruction, creates no risk for the entity. File the signed clauses covering who holds the results, where they are stored, who can access them, how long they are kept, and how they are destroyed. Review these clauses before each engagement, because a standard master agreement signed years earlier may not address the data flows of the current test.
What meeting Article 27 costs in money and effort
This table compares each cost component of meeting Article 27 for TLPT testers, who is paid for it, whether it is one-time or recurring, and what pushes it up. Use it to structure a quote request and to decide which parts to keep in-house and which to buy in.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it up |
|---|---|---|---|
| External tester fees | Accredited or code-of-conduct testers and threat intelligence providers, paid under the contract | Recurring, per threat-led test cycle | Team size, number of tests, and the scope of the threat intelligence work |
| Tester qualification checks | Internal procurement and risk staff reviewing reference lists, certifications and codes of conduct | One-time per provider, repeated at each renewal | Number of providers shortlisted and gaps in the provider's written evidence |
| Professional indemnity and assurance evidence | Tester provider's insurer and auditor, with the entity reviewing the certificates and audit reports | Recurring, as policies and reports are renewed | Provider market conditions and how many reports the entity must collect and track |
| Legal review of contract clauses | Internal legal counsel or outside counsel drafting and negotiating terms on results handling and data destruction | One-time per contract, with updates when scope changes | Complexity of data processing terms and the number of providers engaged |
| Internal approval and verification time | Staff who confirm the tester's suitability, resources and absence of conflicts of interest, and approve internal testers where used | Recurring, per test | Frequency of testing and how many internal testers the entity uses |
| Training and retention of internal testers | Employer funds courses, mentoring and staff time to reach the experience minimums for a test lead and team members | Recurring, as staff rotate and skills age | Capability gaps, staff turnover and the experience levels the RTS requires |
| Threat intelligence and red team capacity | Internal or external specialists covering threat intelligence and red team roles, each with defined experience minimums | Recurring, tied to each test engagement | Whether the team lead meets the required years of experience, and how many references the provider must supply |
Who does what: the entity, a partner, and the authority
The financial entity owns the TLPT programme, decides whether testers are internal or external, signs the contracts, and accepts responsibility for the results and the remediation that follows. Article 27 places the testing conditions on the tester, but the entity remains accountable for choosing a qualified tester and for managing the data the test generates. Internal governance, including the management body's oversight of the test, stays with the entity.
- Tester selection: The entity assesses each tester against the Article 27(1) conditions and keeps records of that assessment.
- Contracts: Under Article 27(3), external tester contracts must ensure sound management of TLPT results and safe handling of data from generation to destruction.
- Internal teams: The entity must show the approval, resources and conflict-of-interest checks that Article 27(2) requires before internal testers take part.
- Remediation: The entity owns the decisions and fixes that follow from findings.
- Evidence retention: The entity keeps the test records that a competent authority may request.
Before engaging anyone, confirm with your competent authority how it expects the tester conditions to be documented.
An implementation partner can help the entity prepare the systems, documentation and tooling that support a TLPT programme. Its work is preparation, not testing authority. DeployOpen, for example, plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and runs security testing and red teaming. Where DeployOpen is engaged for the TLPT programme, it prepares evidence and tooling for the entity's testers. It does not certify testers, does not issue attestations, and does not replace the independent auditor or assessor.
- Evidence preparation: Organizing records of tester qualifications, reference projects, insurance and assurance reports for the entity's file.
- Tooling and environments: Building the isolated test environments, logging and evidence collection the programme needs.
- Documentation: Drafting the TLPT risk management records and handover material, for review by the entity.
- Scope boundary: Keeping a written statement of what the partner delivers and what remains with the entity or the authority.
- Exit readiness: Ensuring the entity can run the programme without the partner after handover.
Ask any partner to state in writing which deliverables are preparation and which are decisions reserved to the entity, the testers or the authority.
The competent authority supervises DORA compliance for each type of financial entity, and a designated TLPT authority may be appointed to handle TLPT matters. Under Article 27(2), the relevant authority approves the use of internal testers and checks the dedicated resources and absence of conflicts of interest. The authority also reviews the attestation that a threat-led penetration test met the requirements, which Article 26(7) provides for. These are the only authority-issued attestations DORA provides for, and the authority does not design the test or act as a tester.
- Internal tester approval: The authority decides whether an entity's internal team may be used.
- Resource and conflict checks: The authority verifies dedicated resources and the absence of conflicts of interest.
- Attestation review: The authority reviews the test attestation under Article 26(7).
- Supervisory follow-up: The authority can request records and may act on findings through its supervisory powers.
- Local practice: Procedures and designated authorities differ by member state.
Confirm the designated TLPT authority and its submission requirements with your supervisor before planning the programme.
Where entities fall short on tester requirements
Most shortfalls against Article 27 come from paperwork that looks complete but cannot be verified. The cards below cover the gaps we see most often, from unverified tester claims to contracts and insurance that stop short of TLPT work. Each one ends with a check the organization can run before a test starts.
Relying on marketing claims
Provider brochures often state that testers are highly experienced or certified, but Article 27(1) requires verifiable suitability, expertise and certification or code-of-conduct adherence. Ask for named individuals, their role histories and the accreditation or ethical framework each provider relies on, then check those records directly. Keep the verification file with the procurement records so an assessor can see how the claims were tested. Request primary records, not summaries.
Internal teams below the employment rule
Internal testing teams under the TLPT RTS need a test lead and at least two other members, all employed by the entity or an ICT intra-group provider for the preceding 12 months. Teams assembled from contractors, recent hires or staff on secondment often fail this test without anyone noticing. Check each member's employment start date against the test date before approval, and record the intra-group arrangement if one provider employs them.
Missing conflict checks for operators
Staff who run production systems, manage the same platforms they test or hold admin rights over them create a conflict that Article 27(2) requires the entity to rule out before internal testers are approved. Many organizations document a conflict-of-interest policy but never check it against the specific people on the TLPT team. Build a written check that compares each tester's operational duties and access rights with the systems in scope, and have the approving authority see it.
Contracts that stop at delivery
Article 27(3) requires external-tester contracts to govern how TLPT results are handled, and that any processing of the data, from generation to destruction, creates no risk for the entity. Many contracts specify the final report and nothing about raw evidence, credentials harvested during the test, interim notes or deletion certificates. Write clauses for each stage of the data lifecycle, name who holds each copy, and set a destruction method and a confirmation step.
Insurance that excludes TLPT work
Article 27(1) requires testers to hold professional indemnity insurance, but a general policy may exclude intrusive testing, red team activity or work against live production systems. A policy that covers only advisory services leaves the entity exposed if a test disrupts a critical function. Ask the insurer in writing whether the policy covers threat-led testing, confirm the limits and exclusions, and attach the certificate to the engagement file before testing begins.
Threat intelligence reference gaps
The TLPT RTS sets reference minimums for providers: at least three references for threat intelligence work and at least five for testers. Providers sometimes list engagements that were small, unrelated to financial services or delivered by staff who have since left. Ask for references that match the team proposed, confirm they cover the required service type, and check that the threat intelligence provider is external to the entity as Article 27(2) requires.
Questions about DORA Article 27 tester requirements
Can our internal security team run a threat-led penetration test under DORA?
Yes, but only in narrow conditions. Under Article 27(2), internal testers may be used only if the competent authority or designated TLPT authority approves their use, verifies that they have sufficient dedicated resources, and confirms there are no conflicts of interest. The threat intelligence provider must also be external to the entity. Article 26(8) adds that entities using internal testers must contract external testers at least every three tests, and credit institutions classified as significant may use only external testers. Delegated Regulation (EU) 2025/1190 sets the internal team structure, including a test lead and at least two other members employed by the entity or an ICT intra-group provider for the preceding 12 months. Confirm the approval route with your competent authority before planning any internal test.
What experience minimums apply to TLPT testers?
Delegated Regulation (EU) 2025/1190 sets the minimums in its TLPT RTS. A threat intelligence team must be led by a manager with at least 5 years of experience and include at least one member with 2 years. A red team must be led by a manager with at least 5 years of experience and include at least two testers with 2 years each. External providers must also supply references: at least three for threat intelligence and at least five for testers. Read the current article text on EUR-Lex before you write a tender, because the minimums are the floor, not the target. Ask each provider to map named staff to these roles, with dates and evidence of their experience.
Does a tester certificate alone satisfy Article 27?
No. Article 27(1) asks for several conditions together: the highest suitability and reputability, specific expertise in threat intelligence, penetration testing and red team testing, certification by an accreditation body in a member state or adherence to formal codes of conduct or ethical frameworks, independent assurance or an audit report on the tester's TLPT risk management, and professional indemnity insurance. A certificate covers only one of these. Ask for each element separately and check that it applies to the people who will actually run your test. DeployOpen can help prepare your own evidence, but it does not issue certificates or assurance reports. Those come from independent bodies.
How long does verifying a tester take, and what do we need to provide?
The time depends on how much evidence each provider already holds and how quickly your team can review it. No fixed duration is set in the supplied sources, so confirm timing with your competent authority and the provider in writing. Your side typically needs to gather the tester's credentials, reference letters, codes of conduct, assurance or audit reports, insurance certificates, and the staffing plan showing who leads and who executes. For internal testers, you also need evidence of dedicated resources and a conflict-of-interest review. Start this work early, because missing documents are the most common reason verification stalls.
Can a partner help us prepare the Article 27 evidence?
Yes. An implementation partner can help you organize the evidence pack, define the tester requirements in your tender, and check that the documents line up with Article 27 and the TLPT RTS. DeployOpen plans, implements and documents systems, and prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Confirm with the partner which tasks sit in its written scope and which remain with your legal, procurement and compliance teams. Your organization stays responsible for selecting testers and for the decision to rely on internal staff.
What drives the cost of meeting Article 27 for TLPT testers?
The cost has several parts, and most are set by scope rather than by a single rate. The main drivers are the number of live systems in scope, the depth of threat intelligence required, the size of the red team, the number of tests in the cycle, and whether external testers must be engaged every third test. Costs also come from preparing evidence, legal review of contracts under Article 27(3), and insurance and assurance requirements placed on providers. Some costs are one-time, such as the first verification and tender, while others recur with each test cycle. The supplied sources do not give fee figures, so ask each provider for a fixed-scope quote with these items listed separately. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it does not publish a price list.
What must our contract with an external TLPT tester cover?
Article 27(3) requires that the contract ensure sound management of TLPT results and that any processing of the data, from generation to destruction, does not create risks for the entity. In practice, the contract should set out how findings are stored, who can access them, how long they are kept, how they are destroyed, and how the tester handles sensitive threat intelligence. Include confidentiality terms, liability and insurance requirements, and a clear route for reporting incidents discovered during the test. Have legal counsel review the terms against your own data handling obligations before signing.
How DeployOpen supports tester evidence for a TLPT
DeployOpen does not certify testers, issue attestations or act as the auditor or competent authority for a threat-led penetration test. Those roles sit with the entity, its external testers, the accreditation body that may certify them, and the supervisor that reviews the result. Where an entity runs its own TLPT, DeployOpen can help prepare the systems, documentation and evidence that the entity then presents, but the qualification decisions under Article 27 remain the entity's to make and defend.
The tester qualification file is where most preparation effort goes. An entity that relies on internal testers must show that the competent or designated TLPT authority approved their use, that dedicated resources exist, and that no conflicts of interest arise, and it must show that the threat intelligence provider is external. An entity that contracts external testers must show suitability, expertise, certification or adherence to a code of conduct, independent assurance over the tester's TLPT risk management, and professional indemnity insurance. DeployOpen can organize these records into one indexed file, map each item to the Article 27 condition it supports, and flag gaps such as an expired certificate or an insurance certificate that does not name the engagement. Ask any partner to confirm which documents the competent authority has requested in writing before work starts.
For entities that test internally, DeployOpen can also deliver the security testing and cyber range work that feeds the TLPT programme, such as scenario rehearsals in a private cyber range, so that the internal team's skills and the entity's own records can be demonstrated. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The entity should confirm with its supervisor which parts of this preparation the supervisor expects to see, and should keep the independence of the testing team from the people who run the systems under test documented from the start.
