Core banking security assessment

Why banks commission a core banking security assessment

If your institution is responsible for testing the core ledger and its integrations, a core banking security assessment gives you an evidence-based view of whether unauthorized transactions, privileged misuse, weak trust between systems and uncontrolled change could actually happen, and what it would take to stop them. It proves which controls work in the platform as deployed, not only in the design documents. The DORA obligation is the usual trigger: Article 24(6) of Regulation (EU) 2022/2554 requires financial entities other than microenterprises to run appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions. Confirm with your supervisor and your own function mapping which systems are in that category before you define scope, because the core ledger almost always is.

The risks the assessment addresses sit in a few specific places. Transaction authorization logic, posting and reversal paths, and limit and approval workflows can be abused by a legitimate user or a compromised integration. Administrative and service accounts, batch schedulers and database roles often carry more privilege than any business role needs, so privilege misuse is a common finding. Middleware, payment hubs, fraud engines and reconciliation feeds usually trust the core on the basis of network location or static credentials, which is weak integration trust. Finally, patches, parameter changes, interest and product configuration, and emergency access tend to move through change processes that are not tested against how the system behaves in production. Ask the provider to map test cases to each of these four areas and to state what evidence will show each one was examined.

Core systems differ from general application testing in three ways. First, many are decades-old platforms with proprietary interfaces, batch jobs and end-of-day processing, so the testers need to understand business processes such as posting, settlement and month-end close, not just HTTP traffic. Second, the test often touches live or production-adjacent environments, so testing must be designed around safe-testing rules, agreed transaction limits, test accounts and rollback or quiescence procedures. Third, the findings must be defensible to an auditor or a regulator, which means the methodology, the scope validation and the retest results need to be documented in a form that can be reviewed later. Ask any provider how they will protect ledger integrity during testing and who approves each action that could change balances.

What can be in scope for a core banking assessment

A core banking assessment is only as useful as its boundary. The components below connect through shared identities, data stores and integration paths, so a gap in one scope decision often weakens the others. Each card names the decision the client must make before testing starts.

Core ledger and transaction engine

This is the system of record for balances, postings and transaction state. Decide which ledger instances, product modules and end-of-day processing components are in scope, and whether test accounts or cloned data sets count as production-adjacent. Confirm who approves any test transaction that touches live posting logic, and how reversals will be handled if a test creates a real entry. Ask for a written list of transaction types that will be exercised, so integrity and authorization checks can be reviewed against it.

Payment and messaging interfaces

Payment rails, card switches and messaging gateways carry instructions into and out of the ledger. Decide which message formats, channels and counterparties are included, and whether connections to external networks are tested only in a non-live environment. Agree how message replay, malformed input and duplicate submission tests will be contained so they do not reach a settlement cycle. Document which interfaces carry payment data in scope for PCI DSS.

Internal APIs and middleware

Integration layers, enterprise service buses and internal APIs often trust callers inside the network more than they should. Decide which services, versions and gateways are included, and whether third-party connections terminated at the middleware are covered. Confirm that object-level authorization and business-flow abuse checks will be tested on the same routes that customers and partners use. Ask for an inventory that maps each API to the critical or important function it supports.

Administrative consoles

Back-office consoles allow staff to change limits, reference data, fees and user entitlements, which makes them high-impact targets. Decide which consoles, role profiles and environments are included, and whether staging copies of the console are tested against production-like data. Agree whether the test will use dedicated test operator accounts, and how those accounts will be removed afterward. Confirm which actions are considered destructive and require a named approver during the test window.

Identity and privileged access paths

Core banking estates often rely on directory services, service accounts, break-glass accounts and vendor remote access that sit outside the application's own login. Decide which identity providers, privileged roles and jump hosts are in scope, and whether the test may attempt lateral movement from integration accounts. Confirm how privileged credentials will be handled, stored and rotated during and after testing. Ask which access reviews and logging controls will be checked as part of the assessment.

Batch and reconciliation jobs

Overnight batch runs, interest accrual and reconciliation processes move large volumes of data between systems and are rarely tested directly. Decide which jobs, file transfers and reconciliation outputs are included, and whether tests may inject or alter input files. Agree how test runs will be scheduled so they do not collide with close-of-day processing. Confirm which integrity and audit trail checks will verify that batch results can be relied on after testing.

How the assessment runs from scoping to retest

The sequence turns a core banking scope into a written, approved test plan, evidence of what was tested and found, and a documented retest that shows whether fixes held. Each gate keeps the client in control of systems, data and risk.

Agree scope and rules of engagement
The client and DeployOpen agree in writing which core banking modules, interfaces, integrations, hosting environments and ICT third-party services are in scope, which functions they support, and which are out of bounds. The rules of engagement set testing windows, source IP ranges, contacts for incidents, data handling, stop conditions and whether production-adjacent or test copies of data are used. Done means the signed scope and rules document exists and the client has confirmed which systems are critical or important functions for DORA purposes. Confirm with your own risk and legal teams whether any third-party provider hosting the platform must also consent to testing.
Map assets and data flows
Testers work with the client's architects to map the core banking platform, its databases, middleware, batch jobs, message queues, payment and card switches, and links to channels such as online banking, mobile apps, partner APIs and Swift-related connectivity. The map shows trust boundaries, identity flows, privileged access paths and where sensitive account data is stored or transmitted. Done means the client approves a written asset inventory and data-flow diagram, and the approved map becomes the baseline for test cases.
Run vulnerability scanning and configuration review
Authenticated and unauthenticated scanning covers operating systems, databases, application servers and network devices in scope, with configuration checks against vendor hardening guidance and the client's own baseline. Scans run in windows the client has approved, with throttling set to protect fragile legacy systems. Done means raw scan output is triaged, false positives are documented, and each confirmed item is linked to an asset in the approved map.
Review source code where feasible
Where the client holds custom extensions, integration code, scripts or configuration-as-code, DeployOpen reviews it against secure coding practice and the OWASP Application Security Verification Standard, focusing on authentication, authorization, input handling and cryptographic use. Vendor proprietary code is reviewed only where the license and vendor terms allow. Done means a list of reviewed components, the review method, and findings with file references is provided to the client.
Execute scenario-based tests and penetration testing
Scenario tests check the business controls that matter most, such as payment release limits, four-eyes approvals, account state changes and batch integrity. Penetration testing follows the OWASP Web Security Testing Guide for application layers and the OWASP API Security Top 10 for interfaces, including object-level authorization and abuse of high-value business flows. Testers use only approved accounts and data, and stop when a stop condition is met. Done means each planned test case has a recorded result, evidence, and the client has been told of any finding that could affect live transactions.
Deliver the report and agree remediation
The report sets out each finding with affected assets, reproduction at a defensive level, risk rating, business impact and recommended fix, along with a summary for executives and a record of what was not tested. The client reviews the draft, corrects factual errors, and agrees a remediation plan with owners and priorities. Done means the final report is accepted and the remediation plan is recorded in the client's own tracking system. Retain penetration testing and remediation records for at least 12 months where PCI DSS applies, as required by requirement 11.4.1.
Retest fixed findings and close out
Once the client reports fixes, DeployOpen retests the affected findings under the same rules of engagement and records whether each is resolved, partially resolved or still open. Retest results are added to the report as a dated addendum. Done means the client holds a closing memo listing each finding and its status, which can be shared with auditors, the board or customers, and which informs the next annual test cycle.

Which weakness categories matter most in core banking

This table compares the weakness categories that most often affect core banking platforms and their integrations, with what each looks like in practice, why it matters to the business and how an assessment tests it defensively. Read each row as a test objective to agree in scope, and treat the rows near the top as the first areas to confirm with your own architecture team.

Weakness category	What it looks like in a core banking target	Why it matters and how it is tested
Broken object and function-level authorization	Account, payment or customer record endpoints that accept an identifier but do not confirm the caller owns it, or administrative functions reachable by ordinary channel roles.	Misuse exposes balances, transfers and personal data across customers. Testing uses role matrices with paired test accounts to confirm every object and function check holds at the API layer.
Excessive trust in internal integrations	Core services that accept requests from channel, middleware or batch components without re-checking identity, consent or limits, on the assumption the caller is internal.	A single compromised integration can act as any customer or system. Testing maps trust relationships and checks whether the core enforces authorization independently of upstream components.
Privileged administrative access and logging	Shared or long-lived operator accounts, weak separation between administration and daily operations, and audit trails that omit privileged actions or are writable by administrators.	Privileged paths are where fraud and insider risk concentrate. Testing reviews account inventory, approval workflows, session controls and whether log records are complete, time-synchronized and protected.
Business-flow abuse	Transfer, limit change, beneficiary addition or payment release flows that can be repeated or automated at volume without velocity controls, anomaly signals or step-up checks. OWASP API6 Unrestricted Access to Sensitive Business Flows describes this pattern.	Automated misuse can drain accounts or evade limits before staff notice. Testing reviews the design of rate, velocity and contextual controls and confirms monitoring alerts fire on defined thresholds in a non-destructive way.
Insecure batch and file interfaces	Scheduled file transfers, end-of-day jobs and payment files with weak integrity checks, unencrypted staging areas, shared credentials or no validation of record counts and totals.	Batch paths often run with broad privileges and receive less scrutiny than online channels. Testing reviews transfer protocols, signing and reconciliation controls, and the permissions of the service accounts involved.
Weak change and configuration control	Emergency changes applied directly to production, configuration drift between environments, default settings left in place after upgrades, and patches deferred on core components.	Undocumented change can silently reopen closed weaknesses. Testing compares documented baselines with live configuration and samples change records to confirm approvals and rollback evidence exist.
Exposed or stale segmentation between core and channel tiers	Firewall rules and routing that have accumulated exceptions, flat networks between tiers, or segmentation documentation that no longer matches the running environment.	Segmentation limits how far an attacker moves from a channel into the core. Testing validates controls from the channel side using agreed test paths, and the results support segmentation evidence where a framework requires it.
Test environment exposure	Production-like copies holding live customer data, or test interfaces reachable from channel networks with weaker controls than production.	Non-production systems often hold real data and are easier to reach. Testing confirms data masking, access restrictions and whether test interfaces are exposed beyond their intended audience.

How testing changes across core banking environments

An on-premises mainframe or legacy core usually sits inside the bank's own data center or network segments, so the bank controls every layer from the network to the application. Reachability is often limited to specific zones, batch interfaces, middleware and terminal or API gateways, and some components may run on platforms with few modern security tools, which affects what the tester can safely examine. Because the bank operates the platform, approvals sit with internal change, operations and the core system owner, and the vendor's support contract may still restrict what can be run against the production image.

Reachable surface: Confirm which network zones, middleware, integration queues and administrative interfaces are in scope and which are excluded for stability reasons.
Approvals: Obtain written sign-off from the core system owner, operations, and the change board, with agreed windows for any activity that could affect batch processing.
Vendor split: The bank carries the full operational responsibility, but confirm whether the vendor's license or support terms permit configuration review or testing on the live release.
Safe practices: Favor read-only configuration and access review, and run load or fuzzing only against a restored copy or a dedicated test partition.
Test data: Use masked or synthetic customer records and confirm that no production extracts leave the controlled environment.

Before scoping, ask the bank's vendor and internal team to confirm in writing which activities the support agreement allows on this release.

What drives the cost and duration of a core banking assessment

This table compares the main drivers of effort in a core banking assessment, what each one changes, and how to keep it proportionate. Use it to see where a quote's size comes from and which scope decisions you control. The main takeaway is that the number of interfaces, roles and environments in scope usually matters more than the testing hours alone.

Driver	Why it changes cost or effort	How to keep it proportionate
Integrations and interfaces in scope	Each payment rail, card processor, general ledger feed, KYC service or open banking interface adds its own authentication, message handling and data flows to test.	Agree a named interface inventory with the bank's architecture team and separate those that touch critical or important functions from those that do not.
User roles and privilege levels	Teller, operations, credit, administrator, batch and third-party support roles each need authorization testing, and privileged paths take longer to validate.	Limit testing to roles that can move money, change limits or alter customer records, and document the rest as assumptions.
Environments and access constraints	Testing production-adjacent or restricted environments requires change windows, monitoring coordination and sometimes supervised sessions, which add scheduling and setup effort.	Confirm which environment is the test target early, whether a staging copy mirrors production data handling, and what access the tester will receive.
Depth of source code review	Full review of custom core banking extensions is far more effort than a targeted review of security-relevant modules, and vendor code may be unavailable.	Ask for review of custom code, configuration and high-risk modules only, and state what the vendor will or will not provide.
Business-flow scenario testing	Scenarios such as payment release, limit override, interest adjustment or account opening need test accounts, data setup and multi-step logic, which is the category the OWASP API6 risk describes.	Pick the flows with the highest fraud or operational impact and limit scenarios to those, rather than testing every product.
Coordination with the vendor and hosting provider	Core banking platforms are often vendor-managed or hosted, so consent, contractual terms, shared responsibility and vendor testing rules must be confirmed before work starts.	Collect vendor testing permissions and hosting provider rules during scoping, and name a single point of contact on each side.
Retest scope	Retests after remediation are priced by how many findings and which components they touch, and a vague retest term often leads to disputes later.	Agree in writing which findings are retested, how many retest rounds are included, and how evidence of fixes is handled.
Annual cycle versus one-time work	Initial scoping, testing and the first report are one-time costs. Annual testing under DORA Article 24(6), retests and continuous testing under a retainer recur.	Plan the first assessment as a baseline so later annual cycles reuse the inventory, scope definitions and test accounts.

Which frameworks and regulators expect this testing

Core banking platforms rarely fall under one rule. Which obligations apply depends on whether the system supports critical or important functions, handles cardholder data, carries Swift traffic or exposes open banking APIs. Scope the assessment against each framework your regulator or customers actually cite, and agree that mapping before testing starts.

DORA yearly testing

Article 24(6) requires financial entities other than microenterprises to run appropriate tests at least yearly on all ICT systems and applications that support critical or important functions. For a core banking platform, that means every component on the function's dependency path, including interfaces to payments, general ledger and customer channels. Confirm with your compliance team which functions are classified as critical or important, since that classification sets the asset list for the assessment. Article 25(1) then defines the test types to run, covered in the next card.

DORA test types

Article 25(1) lists the testing toolset: vulnerability scans, source code reviews where feasible, scenario-based tests and penetration testing. Core banking assessments usually combine authenticated vulnerability scanning of the platform and its middleware, configuration review of database and application tiers, and penetration testing of integrations and admin interfaces. Source code review is applicable only where the institution or vendor provides code access, so confirm that before quoting. Scenario-based tests should reflect the operational failures your business continuity plan already assumes.

TLPT scope validation

Delegated Regulation (EU) 2025/1190 Article 2(2) names entities that TLPT authorities require to perform threat-led penetration testing unless their assessment says otherwise, including G-SII and O-SII banks. Under Regulation (EU) 2022/2554, Article 26(2), TLPT covers several or all critical or important functions on live production systems, and the competent authority validates the scope. A core banking platform is a likely candidate for TLPT scope, so align the yearly assessment with the TLPT preparation work rather than running them as separate exercises.

PCI DSS scope for core banking

Core banking is in PCI DSS scope only where it stores, processes or transmits cardholder data, or where it can affect the security of that environment. Confirm the boundary with a data flow diagram before defining testing. If you are a service provider that uses segmentation to reduce scope, requirement 11.4.6 calls for penetration testing of those segmentation controls at least every six months and after any change, twice the cycle that applies to other entities. Where segmentation is not used, the standard's general penetration testing requirements apply to the in-scope systems.

Swift CSCF advisory control

For institutions connected to Swift, control 7.3A Penetration Testing under the *Detect and respond* objective in CSCF v2026 is advisory. It recommends penetration testing to validate the operational security configuration of the Swift-related environment. Because the control is advisory, your auditor may still ask how the decision was made, so document why the test is in scope and which Swift-connected components it covers, including messaging interfaces and connector hosts that sit near the core platform.

FAPI 2.0 for open banking APIs

Mention FAPI 2.0 only where core banking APIs serve open banking flows. The FAPI 2.0 Security Profile requires pushed authorization requests, PKCE with S256 and sender-constrained access tokens using mutual TLS or DPoP. Test those controls on the APIs that expose accounts or initiate payments, and check conformance with the OpenID Foundation's free test suite and self-certification process. Where core banking serves no third-party API traffic, this card does not apply.

What the client receives and whether it satisfies an auditor

The report is the deliverable that an auditor, regulator or customer will test, so the buyer should agree its contents before testing starts. Expect a scope and method section that states which core banking components, integrations, accounts and environments were in scope, which were excluded, and which test types ran (for example vulnerability scanning, authenticated review, scenario-based tests and manual penetration testing). Expect an asset and data-flow map showing the ledger, batch and payment interfaces, middleware, identity provider, administrative consoles and third-party connections. Each finding should carry a severity rating, a plain statement of business impact (such as unauthorized posting, transaction manipulation or exposure of account data), evidence sufficient to reproduce the condition without exploit code, specific remediation guidance, and a retest result showing whether the fix worked.

The report supports three different reviews. For DORA, it forms part of the internal record of testing under Article 24 and Article 25, showing which critical or important functions were tested, when, by whom and what happened to the findings. For a regulator query, it should let your team answer which systems were covered and why the scope was chosen. For an external auditor, it is one input among several. Under PCI DSS requirement 11.4.1, penetration test results and remediation activity results must be retained for at least 12 months, so the retention period and storage location should be set before the first test. If the core banking platform also processes cardholder data, confirm with your assessor whether the same report will serve the PCI DSS evidence file.

A customer or auditor decides whether the report is sufficient, not the testing firm. Before commissioning the work, ask the assessor, your compliance lead and any key customer to confirm acceptance criteria in writing: minimum test coverage, required severity thresholds, how retests are evidenced and whether they expect a specific report format. Plan redaction in advance as well. Reports naming internal hostnames, account identifiers, customer data or security weaknesses should be redacted before sharing with a third party such as a service provider's customer, a cloud host or an external assessor, and the redaction rules should be agreed in the scope document. Confirm with your own legal and compliance teams what must be withheld before any document leaves the organization.

What to check when choosing a core banking testing provider

A core banking assessment touches production-adjacent systems, regulated data and critical services, so the provider you choose matters as much as the test itself. The six criteria below connect experience, method, safety, scope, data handling and follow-up testing, and each one comes with a question to put to a provider before you sign.

Verifiable core banking experience

Ask for experience described in terms you can check: the kinds of core platforms and integration layers tested, the types of tests performed, and the regulated sectors served, without client names. Experience with payment rails, ledgers, batch interfaces and middleware matters more than general web testing. Ask: which core banking components have you assessed, and how would you describe that work to our auditor without naming a client?

Method transparency against public standards

A credible method maps to recognized references such as the OWASP Web Security Testing Guide, the OWASP API Security Top 10 and, for open banking flows, the FAPI 2.0 Security Profile. Ask the provider to show how each test phase is documented and how findings are rated. A provider that cannot explain its method in writing is hard to defend to a regulator. Ask: which public standards does your method follow, and can I see a sample test plan?

Safe testing controls for production-adjacent systems

Core systems often run in production or alongside it, so testing can affect transactions, batch cycles and customer balances. Look for agreed test windows, rate limits on automated tools, read-only default access, test accounts that cannot move real money, and a stop procedure with named contacts. Confirm that destructive techniques are excluded unless explicitly approved. Ask: what controls prevent a test from disrupting settlement or customer transactions, and who can halt it?

Written scope and rules of engagement

Before work starts, the scope should name the systems, interfaces, environments, source IP addresses, permitted techniques, excluded functions and time windows, and the rules of engagement should define escalation and communication. For DORA-driven assessments, record which critical or important functions the test covers. Fixed-scope agreements in writing make the boundaries auditable and make quotes comparable. Ask: will you provide a signed scope and rules of engagement before any testing begins, and what changes would require a new written agreement?

Handling of confidential data and access

Assessors often receive configuration files, architecture diagrams, credentials for test accounts and sometimes customer-like records. Ask how access is granted, how credentials are stored and revoked, where evidence is kept, how long it is retained and who can see it. Data minimization, encrypted storage and deletion at engagement close should be stated in the contract, not assumed. Ask: how do you limit access to production-derived data, and how is evidence deleted or returned at the end?

Retest and retainer options

Findings only reduce risk once they are fixed and verified, so ask how retesting is priced and scoped, whether it is included in the original quote, and how remediation evidence is delivered. For continuous assurance, ask about retainers covering periodic testing after changes to the core platform. Note that DeployOpen is not an official partner or certified provider of any vendor or standards body unless stated otherwise. Ask: what does a retest cover, and how would a retainer schedule testing after major core releases?

How long a core banking assessment takes and what it needs from the bank

How long does a core banking security assessment take?

The duration is set in the written scope, and no fixed figure applies to every bank. The main drivers are the number of systems and interfaces in scope, how many integrations and channels sit behind the core, how many environments are tested, whether testing is white box or black box, and how quickly the bank can provide access, accounts and decisions. A narrow assessment of one core module and its batch interfaces takes far less time than a review spanning the core, payment hubs, channel APIs and third-party connections. Ask any provider to show how each phase, including environment readiness and reporting, maps to the scope document before you commit.

What does the bank need to provide before testing starts?

Most delays come from missing inputs rather than from the testing itself. Prepare the following before work begins:

An architecture overview showing the core, its databases, middleware, payment hubs and hosting zones
An interface inventory listing APIs, message queues, file transfers and third-party connections, with owners and data classes
Test accounts at each role level, with agreed usage rules and cleanup steps
Named technical, business and incident contacts who can make decisions during testing
Change freeze windows and batch cut-off dates so testing does not collide with end-of-day, month-end or release activity

Agree how sensitive customer data will be handled, masked or excluded before any account is used.

Can the bank's own security team run the core banking assessment?

Internal teams can perform useful vulnerability management, configuration review and some testing, but they usually cannot provide the independence that regulators and auditors expect for a formal assessment. DORA requires testing to be appropriate and carried out by qualified parties, and the bank must be able to show who tested, how they were qualified and whether they were independent of the system's build and operation. Internal staff who built or run the core are likely to be too close to it for an independent view. A common model is internal teams handling continuous scanning and remediation, with an external provider performing the scoped assessment and retest. Confirm the independence and qualification expectations with your own compliance function and supervisor.

Is production testing of a core banking system allowed under DORA?

Testing on live production systems is not a general permission under DORA. Threat-led penetration testing under Article 26 is performed on live production systems, but only as a validated TLPT exercise with scope approved by the competent authority. For a standard assessment under Article 24(6) and Article 25, the bank should test production-adjacent environments that mirror the live configuration, such as a staging copy with representative data, and limit any live testing to low-impact checks agreed in writing. Define safety rules for denial of service, data access, account lockouts and payment-affecting actions before testing starts. Confirm the approach with the bank's own risk and operations teams.

How is retesting priced and scheduled?

Retesting is usually scoped separately from the original assessment, and its effort depends on how many findings are reported for retest, how complex each fix is, and whether the fix requires a new build or only a configuration change. Ask for retest terms in the quote, including the window after the report during which retests are included, how evidence of remediation is accepted, and whether a retest of a fix that changed the architecture needs a fresh scope. Plan retest windows around the bank's change calendar, because a fix cannot be verified until it is deployed to the tested environment.

How does a core banking assessment connect to a later TLPT?

A structured assessment is a sensible precursor to threat-led testing. It gives the bank an inventory of critical or important functions, a tested view of their weaknesses and a remediation record, which are inputs the TLPT scope and the threat intelligence work will need. Delegated Regulation (EU) 2025/1190 sets out which entities a TLPT authority requires to test, and TLPT itself is validated by that authority, so the assessment does not replace it. Keep the assessment report, remediation evidence and asset list in a form that can be reused. Confirm with your competent authority whether your entity is in scope for TLPT and when.

How DeployOpen scopes, tests, reports and retests core banking systems

DeployOpen agrees a written, fixed scope for each core banking assessment before testing starts, covering the platform, its integrations and the environments in scope. Testing, documentation and retesting then follow that scope, with ongoing support available as a retainer.

How we scope

Confirm which systems support critical or important functions, since those define the DORA yearly testing boundary.
List core ledger, payment processing, integration middleware, and identity components, with owners and data flows for each.
Agree in writing which environments are in scope, including production-adjacent staging or test copies with matching configuration.

How we build

Set test methods per component, such as vulnerability scanning, configuration review, source code review where feasible, and penetration testing.
Agree safe testing rules for production-adjacent systems, including change windows, rate limits, backup checks and stop conditions.
Include scenario-based tests of business flows, such as transfers and limit changes, to check misuse by automated means.

How we hand over

Deliver a written report with findings, affected components, evidence and prioritized remediation steps for your engineering teams.
Provide a remediation tracker so results and fix activity can be retained and shown to auditors or regulators.
Confirm with your auditor or regulator what format and retention they expect before the report is finalized.

How we support

Retest agreed findings once fixes are in place and document whether each issue is closed, partly closed or open.
Advise on readiness for threat-led testing where your competent authority requires it, without issuing any attestation.
Offer ongoing support and continuous testing as a retainer, with scope and deliverables agreed in writing.