What DORA requires of payment and e-money institutions and who pays for it
DORA applies to payment institutions and electronic money institutions under Article 2(1), and PSD2 incident reporting no longer applies to them under the amended Article 96(7), so one incident regime now covers all operational or security payment-related incidents, whether ICT-related or not. The organization owns its controls and decides how it meets them. An implementation partner can prepare systems, configurations and evidence, but only the national competent authority supervises compliance, and no partner can issue a report or attestation on the firm's behalf. A customer, bank partner or regulator asking for DORA evidence is therefore asking the firm to show its own controls working, with the supporting records ready for inspection.
The actual work depends on four variables that a firm should settle before requesting any quote. The first is exemption status: payment and e-money institutions exempted under PSD2 and the E-Money Directive fall under the simplified ICT risk management framework of Article 16 instead of the full Chapter II regime. The second is payment volume and outstanding e-money, because the TLPT RTS in Delegated Regulation (EU) 2025/1190 lists institutions above EUR 150 billion of payment transactions, or EUR 40 billion of outstanding e-money, in each of the two preceding years among the entities authorities require to test, unless their assessment says otherwise. The third is the degree of outsourcing to ICT providers, which drives contract review, the register of information and exit planning. The fourth is the competent authority's own expectations. Costs are mostly recurring staff time, tooling, testing and evidence upkeep, and a quote should separate one-time gap analysis and remediation from ongoing operations. The Commission's Digital Omnibus proposal COM(2025) 837 would change how major incident reports are routed under NIS2, and firms should confirm its status with their authority before finalizing reporting procedures.
What a DORA programme for a payment institution costs and who is paid
This table lists each cost component of a DORA programme for a payment or electronic money institution, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for a written scope quote and to check that each cost line has an owner. No figures are given because none are supplied for this topic, so confirm amounts against your own scope and with your competent authority.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives cost up or down |
|---|---|---|---|
| Internal staff and governance time | Your own staff and management body, not an outside party | Both: one-time setup of the framework, then recurring review and approval | Size of the institution, number of payment services and countries served, and how many policies already exist for PSD2 security work |
| Implementation partner work on the ICT risk framework | External implementation partner, under a written scope | Mostly one-time, with recurring updates after reviews or major changes | Number of ICT systems in scope, how much existing documentation can be reused, and the gap between current practice and the Chapter II requirements |
| Register of information and third-party inventory | Internal compliance and procurement teams, plus partner support if requested | One-time build, then recurring maintenance and submission to the competent authority | Number of ICT third-party arrangements, subcontracting chains and how well contract data is already recorded |
| Incident management process and reporting workflow | Internal security operations and compliance, with partner help on process design | One-time design, recurring operation and exercises | Volume of operational and security payment-related incidents, reporting channels required, and whether one regime is set up for all payment incidents under Article 23 |
| Tooling and monitoring | Software vendors or open-source components operated by your team or a partner | Often recurring licensing or hosting, plus one-time integration | Choice between self-hosted open-source tools and commercial products, logging volume and retention needs |
| Independent testers where TLPT applies | Independent external testers selected by the institution and approved under the TLPT rules | Recurring at the testing cycle set by the authority | Whether the institution falls under the TLPT thresholds in Delegated Regulation (EU) 2025/1190, the scope agreed with the authority and the number of live production systems tested |
| Supervisory reporting and authority interaction | Internal regulatory reporting teams, with possible external advisers | Recurring, tied to reporting deadlines and supervisory requests | Number of authorities involved, frequency of requests and the quality of evidence already held centrally |
How one incident regime replaces PSD2 reporting for payment incidents
Payment institutions and electronic money institutions now report operational and security payment-related incidents under DORA alone. Article 23 applies the incident management, classification and reporting requirements of Chapter III to operational or security payment-related incidents at these firms, and to major ones. Directive (EU) 2022/2556 supports this by adding Article 96(7) to PSD2, which switches off the separate PSD2 incident reporting duties in Article 96(1) to (5) for payment service providers covered by DORA. The practical result is one reporting channel, one set of templates and one clock, instead of two overlapping regimes that could each be triggered by the same event.
The scope is broader than many teams expect. The regime covers payment-related incidents whether or not they stem from ICT, so a branch closure, a failed manual reconciliation or a third-party process breakdown that disrupts payment services can fall within it, not only a system outage or cyberattack. Firms should therefore run classification on the payment impact of an event, not only on its technical origin. Before the next incident, confirm with the competent authority which templates, submission channel and timelines apply to your licence type, and whether it expects initial, intermediate and final reports for payment incidents in the same format as ICT incidents.
Preparing for this means a single internal process. Define one classification method that scores impact on clients, payment volumes, duration and reputational harm, and assign one owner who decides whether an event is major and who files the report. Map the data fields the authority requires to the logs your payment and ICT systems already produce, so that the first report can be assembled within the deadline. Test the process with a tabletop exercise that includes a non-ICT payment failure. Where a legacy PSD2 procedure still exists in a runbook or contract, retire it deliberately so that staff do not file the same event twice.
Which payment and e-money institutions get the simplified framework
Authorized payment institutions and authorized electronic money institutions sit within the full scope set by Article 2(1). Full scope means the complete ICT risk management framework of Chapter II, the incident management and reporting regime of Chapter III, the testing programme of Chapter IV, and the third-party rules of Chapter V apply in full, with proportionality under Article 4 still shaping how each control is sized. Your competent authority under Article 46 is the PSD2 authority for payment institutions and the authority designated for e-money institutions.
- ICT risk framework: A documented framework with a management body that approves and oversees it, reviewed at least yearly as the Regulation requires.
- Incident regime: Operational or security payment-related incidents follow Article 23, and PSD2 incident reporting no longer applies to you.
- Testing programme: Basic testing of ICT tools and systems applies to you, and TLPT applies only if you cross the thresholds in Delegated Regulation (EU) 2025/1190.
- Third-party register: Contracts with ICT providers must be recorded and managed under Chapter V.
- Business continuity and backup: Full continuity planning and recovery testing apply.
Confirm with your authority that your licence or registration is not subject to any exemption before you treat full scope as settled.
Article 2(1)(b) and (d) bring payment institutions and electronic money institutions that are exempted under PSD2 and the E-Money Directive into DORA, but route them to the simplified ICT risk management framework in Article 16 rather than the full Chapter II regime. The exemption is a status question, so the firm should not assume it qualifies. The simplified framework still requires a documented, risk-based ICT approach, and the incident reporting and resilience obligations that the Regulation sets out for payment-related incidents continue to matter for these entities.
- Still mandatory: ICT risk controls proportionate to the firm's size and risk profile, documented and kept current.
- Relaxed: The full governance and documentation burden of Chapter II is reduced to what the simplified regime requires.
- Still mandatory: Incident handling and reporting for operational or security payment-related incidents under Chapter III.
- Relaxed: Formal testing expectations scale down compared with full-scope firms.
- Confirm first: Whether your exemption under PSD2 or the E-Money Directive is current and in effect.
Ask your authority in writing to confirm exemption status, and keep that confirmation with your DORA file.
Many firms cannot answer the scope question from memory, because exemption depends on thresholds and conditions set in the payment and e-money legislation, not on how large the firm feels. The sensible first step is to pull your authorization or registration file and compare it with the exemption conditions your authority applies. Where the answer is unclear, treat it as an open question and resolve it with the authority before you scope your DORA programme.
- Authorization record: Locate the licence or registration decision and any conditions attached to it.
- Exemption conditions: Compare your current activity against the conditions for exemption under PSD2 and the E-Money Directive.
- Change tracking: Re-check status when transaction volumes, outstanding e-money or product lines change.
- Group structure: Confirm whether any intra-group or agent arrangements affect the analysis.
- Written confirmation: Request a written statement of your status from the competent authority.
Record the date of your status check and the authority's response, because you will need it when a supervisor asks how you reached your scope decision.
When TLPT applies to payment and e-money institutions
Threat-led penetration testing is not automatic for every payment or e-money institution. The cards below explain the size thresholds in Delegated Regulation (EU) 2025/1190, how to check them over two years, what to do when a firm sits close to a limit, and how TLPT differs from the basic testing every firm must run.
The EUR 150 billion payment threshold
Article 2(2) of Delegated Regulation (EU) 2025/1190 lists payment institutions whose payment transactions exceed EUR 150 billion in each of the two preceding years. Those firms are presumed to be in scope for threat-led penetration testing unless the competent authority's assessment decides otherwise. Confirm the figure your firm reports against this list, using the payment volume definitions in the regulation itself, before assuming you fall outside it.
The EUR 40 billion e-money threshold
Electronic money institutions face a parallel test based on outstanding e-money. Where the outstanding amount exceeds EUR 40 billion in each of the two preceding years, the institution appears on the same Article 2(2) list. Finance and risk teams should calculate the outstanding figure on the same dates each year so the two-year test is reproducible for the authority.
Testing the two-year condition
Both thresholds require the limit to be exceeded in each of the two preceding years, not in one peak year. A firm that crossed the line in one year only should record the figures for both years and keep them as evidence for its supervisor. Ask your compliance lead to document the calculation method and the source of each year's figure in the register of supervisory evidence.
Firms near the threshold
A firm whose volumes hover close to EUR 150 billion or EUR 40 billion should not wait for the year-end figure to decide. Track payment and outstanding e-money monthly, agree the trigger point with your competent authority, and prepare a TLPT readiness plan before the second consecutive year crosses the line. Growth through acquisitions or new products can move a firm over the limit faster than expected.
Authority power to require testing
The list in Article 2(2) is not the only route into TLPT. The competent authority can require threat-led testing from other payment or e-money institutions where its own risk assessment justifies it. Ask your authority whether it has issued a decision or assessment on your firm, and keep a written record of any request, its reasoning and your response.
TLPT is distinct from basic testing
Basic testing of ICT tools and systems under Chapter IV applies to every payment institution and e-money institution, regardless of size. Threat-led penetration testing is a separate, intelligence-driven exercise on live production systems and critical functions that is only required for firms within scope. Budget and staffing for basic testing should not be treated as already covering TLPT.
How a payment institution moves from scoping to a supervisory-ready DORA file
This sequence takes a payment or e-money institution from a settled view of its entity type to a file its management body has approved and its competent authority can review. Each phase produces a named output that feeds the next, so gaps surface early and remediation is tracked against evidence.
Confirm entity type and exemption status
Start by establishing which DORA entity type the institution is under Article 2(1), and whether it is a payment institution or electronic money institution that is exempted under PSD2 or the E-Money Directive. Exempted institutions fall under the simplified ICT risk management framework of Article 16, so this answer sets the depth of every later phase. Confirm the position with the national competent authority if the classification is uncertain. The output is a short written scoping memo, signed by the person accountable for compliance, that records the entity type, the exemption status and the TLPT threshold position against the figures in Delegated Regulation (EU) 2025/1190.
Run the gap analysis against Chapter II and the incident regime
Compare current ICT governance, risk management, incident handling and reporting practice against the requirements of Chapter II and Chapter III, including the payment-related incident rules in Article 23. The gap analysis should also map where PSD2 incident reporting under Article 96 is replaced by the single DORA regime. The output is a gap register that lists each requirement, the current state, the evidence that exists today and the owner of the fix. Ask the implementation partner to confirm that the register covers both ICT-related and non-ICT operational or security payment incidents, since the single regime reaches both.
Build the register of information and third-party inventory
Inventory every ICT service the institution uses, including payment processing platforms, cloud hosting, fraud and monitoring tools, and any self-hosted open-source components that the institution operates itself. Record which services support critical or important functions, which providers sit in subcontracting chains and where data is processed. The output is a complete register of information in the format the supervisory authority expects, reconciled against contracts and the asset inventory. Confirm the required template and submission channel with the competent authority, because the register is reviewed as a supervisory record.
Remediate ICT controls and contracts
Close the gaps in the register, prioritizing controls for critical or important functions and contracts that lack the provisions Article 30 requires. Remediation may include hardening self-hosted platforms, tuning logging and monitoring, updating incident classification procedures, and renegotiating provider terms or exit arrangements. Each change should be tied to a gap register entry and a named owner. The output is a remediation log showing the change, the date it was made, the test or configuration evidence that proves it, and the gap entry it closes.
Test controls and collect evidence
Run the basic ICT testing that DORA requires of every entity, and confirm that tests of incident response, backup restoration and business continuity produce recorded results. Where the institution falls inside a TLPT threshold, plan threat-led testing through the authority's process rather than assuming it applies. Collect evidence in a single repository organized by requirement, with test scope, results, remediation status and retest outcomes. The output is an evidence pack that an independent reviewer can trace from each requirement to a test record and a remediation entry.
Obtain governance sign-off from the management body
Present the scoping memo, gap register, register of information, remediation log and evidence pack to the management body, which carries responsibility for the ICT risk management framework and must approve it. Record the discussion, questions raised and the decisions taken, including any residual risks the body accepts. The output is signed minutes and an approved framework document with a review date. Treat this as the final gate: a file that the management body has not reviewed will not hold up well when the competent authority asks who approved the risk position.
What makes DORA more expensive or slower for a payment firm
For a payment or e-money institution, the cost and pace of DORA compliance depend less on the rulebook than on the shape of its own estate and supplier base. The cards below cover the drivers that most often stretch budgets and schedules, and the controls that keep them in check.
Outsourced payment processing contracts
Many payment firms run card processing, settlement or fraud screening through third-party providers, and each of those relationships must meet the contractual requirements of DORA's third-party chapter. Existing agreements often lack audit rights, incident cooperation clauses or exit provisions, so remediation means renegotiating contracts across the whole supplier base. Start by listing every processor, then check each contract against the required clauses before deciding what to amend and what to replace.
Number of ICT services in scope
Every ICT service that supports a payment flow, from API gateways to reconciliation tools, adds inventory, risk assessment, testing and register entries. A firm with many small SaaS tools may carry more administrative load than one with a few large platforms. Build a single inventory that maps each service to the business function it supports, and retire unused tools before counting the workload.
Self-hosted versus cloud estate
A self-hosted estate keeps control of configuration, logging and patching in-house, which means the firm must evidence those controls itself. A cloud-heavy estate shifts some technical work to providers but adds concentration and subcontracting questions that must be documented and contracted. Decide the hosting model per payment workload early, because switching later means re-testing and re-registering services.
Legacy payment systems
Older core banking, switching or card management components often lack modern logging, encryption or patch support, and they may depend on vendors that no longer issue security updates. Each unsupported component needs a documented risk decision, compensating controls or a replacement plan. Ask whether vendors still ship patches for each legacy system, because that answer usually determines the remediation effort.
Incident reporting maturity
Payment-related incidents follow the same reporting regime as other operational or security incidents, so the firm must classify, time and report them consistently. Teams without a defined classification method, a log of incident timelines or a tested escalation path spend extra time reconstructing events under deadline pressure. Run a tabletop exercise against a realistic payment outage to find where the process breaks before a regulator asks.
Group intra-company services and TLPT scope
Payment firms that belong to a banking or fintech group often receive shared IT, hosting or fraud services from group entities, which DORA still treats as ICT services requiring documented arrangements. Whether the firm falls within threat-led penetration testing scope depends on its payment volume against the thresholds set in the delegated regulation, and a test in scope is far more costly than basic testing. Confirm the transaction and e-money figures with the competent authority early, and agree written intra-group service terms before the testing decision.
Who owns the controls, who prepares evidence and who supervises
The payment or e-money institution owns every DORA control. Its management body remains accountable for the ICT risk management framework, approves the policies that DORA requires and signs off the resilience strategy, the incident process and the register of information. Staff who run payment systems, fraud monitoring and customer-facing channels carry day-to-day responsibility for those controls. An implementation partner such as DeployOpen can configure logging, harden self-hosted platforms, assemble test evidence and draft documentation, but it cannot accept risk on the institution's behalf or approve a policy in its place. Before work starts, the institution should record in the written scope which decisions stay with its own management body and which named individuals will review each deliverable.
Evidence is prepared by the implementer, but it is read by the institution and by its supervisor. A partner's role is to produce system configurations, access reviews, backup restore records, vulnerability scan outputs and incident runbooks that the institution can present. The institution should confirm that its own staff can explain and reproduce each artifact, because the supervisor will ask the institution, not the partner, about its controls. DORA sets no certification scheme. Supervision of compliance falls to the national competent authority designated under Article 46 for payment and e-money institutions, which is typically the authority that already supervises PSD2 licensing in that member state. Your national authority, not an external certificate, determines how it wants evidence presented, so ask it early which format and level of detail it expects.
The only attestation DORA provides is for threat-led penetration testing, and DeployOpen cannot issue it. Under Article 26(7), the attestation that a threat-led penetration test met the requirements comes from the authority, and only testers that meet the requirements set out in DORA and its technical standards can carry out that test. Payment and e-money institutions above the transaction or outstanding e-money thresholds in Delegated Regulation (EU) 2025/1190 should confirm with their competent authority whether they are required to test. DeployOpen runs security testing and prepares systems for assessment, but it issues no reports, attestations or certificates of its own. Any statement that a platform or partner is DORA compliant should be treated with caution; compliance is a status the institution demonstrates to its supervisor.
How to choose a DORA partner for a payment or e-money firm
A payment or e-money institution buying DORA help needs a partner that understands PSD2 payment operations, can produce evidence a competent authority will accept, and stays out of the testing it prepares for. The cards below set out what to check before signing and what to settle in writing.
Payment operations experience
Ask whether the partner has worked on PSD2 payment flows, fraud and transaction monitoring, and settlement dependencies, not only generic ICT controls. Under Article 23, operational and security payment-related incidents fall under the DORA regime even when they are not ICT-related, so the partner must map payment processes to ICT services, not just servers. Ask how they would classify a failed payment batch caused by a provider outage and who in your organization decides the classification.
Evidence the authority can test
The partner should be able to show how each control produces records a national competent authority can inspect: incident logs, change approvals, access reviews, backup restore results and register entries. Ask for an example evidence index mapped to DORA articles, with owners and retention periods agreed in advance. Evidence that exists only in a consultant's workspace will not help you in a supervisory review.
Independence from TLPT testers
If your institution may fall under threat-led penetration testing, the firm that prepares your systems should not also be the tester that attacks them. Ask whether the partner offers security testing and, if so, how it separates preparation work from the testing engagement. Confirm with your competent authority which testers it accepts, because the requirements for external testers and the authority's role in TLPT are set out in the regulation and the TLPT technical standard.
Written fixed scope
Require a written scope that lists the entities, payment services, ICT systems, third parties and deliverables covered, plus the dates on which each deliverable is due. Most engagements of this kind are fixed-scope, so changes should go through a written change request with a revised quote. Check that the scope states which regulatory obligations are in and which are out, and that it does not promise a regulatory outcome, since only an authority can confirm compliance.
Who holds the evidence
Before signing, confirm in writing who owns each policy, log, configuration record and test result, and where it is stored. Your institution should hold final custody of everything it must present to the authority, in systems it controls. Ask whether the partner will leave working files, scripts and runbooks in your repositories at handover, and what happens to access credentials when the engagement ends.
Exit and handover terms
Ask how the partner ends the engagement and what you keep. A sound exit plan covers returning source configurations, documentation in editable formats, removal of partner access, and a handover session for your staff. Because DORA treats exit from ICT services as a third-party risk matter, the same questions apply to the partner itself. Request the exit terms in the contract, not in a separate email.
Questions payment and e-money institutions ask before hiring help
Does DORA replace PSD2 incident reporting for our payment institution?
Yes, for operational and security payment-related incidents, and that is the change that matters most for your reporting desk. Directive (EU) 2022/2556 added Article 96(7) to PSD2, so PSD2's own incident reporting no longer applies to payment service providers covered by DORA. You report payment-related incidents under Chapter III of DORA, including Article 23, whether the root cause is ICT-related or not. The result is one regime, one set of templates and one clock. Confirm with your competent authority how it expects you to classify a payment incident with no ICT element. Then check whether your incident log, classification thresholds and escalation contacts still reflect the PSD2 process, since they will need rewriting for DORA.
Are exempted payment and e-money institutions in the simplified regime?
Yes, if your authority has granted the PSD2 or E-Money Directive exemption, your ICT risk management falls under the simplified framework in Article 16. DORA's scope in Article 2(1)(b) and (d) includes exempted payment institutions and electronic money institutions. Being exempted from the sectoral rules does not take you out of DORA, though. The simplified framework reduces documentation and governance effort, but you still need an ICT risk framework, incident handling, testing and third-party controls that your authority can inspect. Ask the authority which simplifications it accepts in practice. Record the scoping decision in writing and review it whenever your exemption status changes, because your DORA position changes with it.
When does threat-led penetration testing apply to payment institutions?
Threat-led penetration testing (TLPT) applies when your authority requires it, and Delegated Regulation (EU) 2025/1190 sets the starting thresholds for payment and e-money institutions. Its Article 2(2) lists entities that authorities must test unless their assessment says otherwise. For these institutions, the listed trigger is payment transactions above EUR 150 billion, or outstanding e-money above EUR 40 billion, in each of the two preceding years. Staying below those levels does not settle the question, because the authority still decides your position. Ask for its view in writing. If you are in scope, the test must follow a threat-led method, and TIBER-EU is one recognized route to meeting DORA's requirements. Confirm the scope, timetable and tester arrangements with your authority before you commission anything.
What does DORA preparation cost, and who gets paid?
The regulation sets no price, so the cost depends on the scope you agree. The main components are internal staff time for governance, risk assessment, policies and evidence, which is heavy for the first build and recurs afterward; software and hosting for the platforms in scope; an implementation partner, if you use one, paid under a written, fixed scope; and specialist testers if TLPT or penetration testing applies. Recurring costs include reviews, testing, exercises, register updates and support. The main drivers are the number of ICT systems and providers, how well your estate is already documented, whether payment incidents are logged in a usable form, and whether TLPT applies. DeployOpen does not publish a price list. A quote follows from a written scope that names systems, deliverables and timelines. Ask every bidder to split one-time from recurring costs and to name who performs each task.
Can a payment institution run DORA compliance in-house?
Yes, many can, and the duties sit with your management body and your own controls. The organization owns its controls. An implementation partner prepares systems, controls and evidence for your review, but it does not issue any DORA report, and only your competent authority supervises compliance. The practical question is capacity and skills: do you have people who can map ICT assets, classify incidents, negotiate and manage contracts with ICT providers, maintain the register of information and keep all of it running after go-live? Some institutions keep governance and sign-off in-house and outsource platform hardening, logging setup or testing. Ask any partner which tasks it will perform, what your staff must still own, and how evidence will be handed over. Confirm with your authority what it expects about external testers before you decide what to keep internal.
How does the pending Digital Omnibus affect our incident reporting?
Until any amendment is adopted, the current DORA reporting rules apply, so build your process on them. The Commission proposed COM(2025) 837 on 19 November 2025. It would amend Article 19 so that major incident reports and voluntary threat notifications go through a single entry point under NIS2. As of October 2026, the European Parliament's Legislative Observatory lists procedure 2025/0360(COD) as awaiting committee decision. The practical risk is building a reporting process that is hard to change. Keep incident templates, escalation contacts and reporting roles in documents you can update quickly, and map each reporting field to the current Article 19 requirements. Ask your authority whether it expects a change to the entry point and how it would tell firms. Track the procedure and review your playbook once the final text is known.
How DeployOpen prepares payment institutions for DORA evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is their cloud accounts, data centers or air-gapped networks. For a payment institution or electronic money institution, the practical work is to put the ICT systems that process payment-related data under a documented control set, then assemble the records that show those controls operate: configuration baselines, logging and monitoring setup, backup and restore records, incident handling runbooks, and the register of information entries for each ICT provider. DeployOpen also runs security testing, so the same team can run the basic testing that DORA expects of every entity and document what was found and fixed. Scope, deliverables and timelines are agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope.
The boundary of that work matters for procurement. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. The institution owns its controls and its incident reporting decisions, and the competent authority named under Article 46 supervises compliance. Before engaging anyone, ask whether the proposed scope covers the specific payment-related incident categories your institution must report under Article 23, whether the register of information fields are drawn from your current contracts, and which evidence items will be delivered in a form your internal audit or your supervisor can review. Confirm whether your institution is exempted under PSD2 or the E-Money Directive, since that determines whether the simplified framework of Article 16 applies instead of the full Chapter II regime.
Ask for a written statement of deliverables that names each evidence artifact, its owner inside your organization, and how often it must be refreshed. Recurring items such as access reviews, backup restore tests and vulnerability scans will need a named internal owner after the engagement ends, and retainers for ongoing support, upgrades and continuous testing are available if you want that load carried externally. Whatever the arrangement, have your compliance lead and an independent reviewer confirm that the evidence answers the obligations in your own jurisdiction, because DeployOpen's role is to prepare what the institution submits, not to judge whether that submission is sufficient.
