When a Fineract penetration test is worth scoping now
A penetration test of an Apache Fineract deployment checks whether an attacker can reach client, KYC and loan data through the platform's own interfaces, and it is worth commissioning before a self-hosted instance is exposed to customers, partners or the internet, or soon after one has been. Commission it when the deployment holds live client and KYC records, when the API or a front end is reachable from outside your network, or when a new tenant, integration or gateway changes what can reach the database. A test run late in the project tends to find design issues that are expensive to change, so the scope decision belongs in the planning phase.
Fineract is headless. It exposes REST APIs and does not ship its own user interface, so the test surface is the API, the multi-tenant model, the gateway in front of it and any front end you add, such as the Mifos X web application that the project's Kubernetes example uses. Each Fineract-Platform-TenantId header and each tenant connection drawn from the tenants database is a boundary to test, because a flaw there can expose one institution's data to another. Confirm with your team which of these components are in your deployment, which are reachable from which networks, and which are planned for later phases, since the scope should match what is live on test day.
The project's README warns that a production deployment can be complex, costly and time-consuming, and that it does not provide a comprehensive production deployment guide. That gap means many deployments reflect the choices of the team that built them, not a documented baseline. Before you request quotes, write down the environments in scope, the owner of each control you expect the test to examine, and whether the test will run against a copy of production data. A written scope with those answers lets a testing partner price the work accurately and lets your team judge whether the findings reflect the system you intend to run.
What a Fineract penetration test should cover
A Fineract test is only as useful as its scope, and these six areas cover where a core banking API is most likely to fail. Each one maps to a trust boundary: who can call what, which tenant data is reachable, what reaches the database, who approves money movement, what sits at the edge, and what defaults survived go-live. Agree the depth of each area in writing before testing starts.
API authorization
Fineract exposes REST endpoints for clients, loans, savings, accounting and administration, and each call must be checked against the caller's role and office. A tester maps every endpoint family, then replays requests with low-privilege and cross-office accounts to see whether reads or writes succeed when they should not. Ask the tester to record which permissions were confirmed by a denied request and which were only assumed from the UI.
Tenant isolation
Fineract is multi-tenant, and API requests select the tenant with the Fineract-Platform-TenantId header. A tester checks whether a valid token for one tenant can be used with another tenant identifier, whether tenant connection details can be inferred from responses, and whether errors reveal other tenants. Test with at least two tenants that hold realistic but non-production data so that a leak is visible without exposing real customers.
Injection in search and reports
Search and report endpoints accept user-controlled filters, sort fields and report parameters, which is where SQL injection risk concentrates in data-heavy platforms. The tester fuzzes these parameters with malformed input, boolean and time-based payloads, and oversized values, and checks error responses for database detail. Confirm the Fineract version in scope and its published security fixes before testing, so that findings are not duplicates of known issues.
Maker-checker bypass
Maker-checker separates the user who creates a transaction from the user who approves it, and a bypass lets one person complete a sensitive action alone. The tester attempts to approve their own request, to approve through a second session or an API call that skips the workflow, and to change a pending item after approval. Record which approval rules are enforced by the platform configuration and which depend on operating procedure.
Front end and gateway
Fineract is headless, so the browser front end, the reverse proxy, the API gateway and any WAF form the real attack surface. A tester checks what the gateway exposes beyond the intended allow-list, whether self-service or test paths are reachable from the internet, how TLS and security headers are set, and whether rate limits and logs capture abuse. Include the Mifos web application or any custom front end in the scope.
Default login and insecure profiles
The project's README documents a development login that must be changed for any real deployment, and development profiles can expose behavior that is unsafe in production. A tester confirms the default credentials are gone, that no test or development profile is active, and that HTTP basic authentication is not reachable where OAuth2 is intended. Ask for the configuration and container images, not only a screenshot of the login page.
How to test API authorization and tenant isolation
Authorization testing for Fineract starts with tenancy. The README describes a multi-tenant design in which each API request carries a Fineract-Platform-TenantId header, and tenant connections are configured from a tenants database. That makes the header a routing choice, not a security boundary on its own. A tester should confirm that a credential issued for tenant A is rejected when the same request is sent with tenant B's header, that list and search endpoints never return records from another tenant, and that write calls cannot change another tenant's loans, savings or client records. Confirm too how your gateway forwards or overwrites that header, because a client-supplied value that reaches Fineract unchanged can be the entire attack.
Role checks need to be tested on every instance type your deployment runs. The Fineract documentation describes read, write and batch instances set by environment variables, and recommends one write instance, one batch instance and multiple read instances on database read replicas. Confirm which roles and permissions apply on each, and whether a read-only user can reach a write or batch path through a route that only the write instance was meant to serve. Also test the authentication paths you actually enabled. The README shows both OAuth2 and HTTP basic authentication, so a tester should check that a token issued by one path cannot be replayed through the other, that basic credentials are refused where OAuth2 is required, and that default development credentials are gone. Record the results per tenant, per role and per instance type so the report shows what was tested, not only what failed.
Document the expected matrix before testing begins. Ask your team to confirm which tenants, roles, permission sets and instance types are live in your environment, and which Fineract users are mapped to which offices. Agree in writing which tenant pairs will be tested against each other and which test accounts the tester may create and remove. Where a finding depends on configuration, such as an enabled self-service API or a tenant with a shared database credential, record the setting and its source so remediation can be verified against the same configuration afterwards.
Black-box, grey-box or white-box: choosing the test approach
A black-box test starts from the outside with no credentials, source code or configuration. The tester sees what an internet or partner attacker would see: the public hostname, the TLS endpoint, the API gateway and any WAF in front of Fineract. This approach is useful for checking the edge, including whether administrative or self-service paths are reachable and whether error responses leak internal detail. It tests whether the exposed surface is what you think it is. It is weaker at authorization because testers cannot see which roles exist or which tenant a user belongs to, so object-level and tenant isolation checks are often shallow.
- What it finds well: exposed admin or actuator paths, missing gateway allow-lists, verbose errors, weak TLS and headers, and unauthenticated endpoints.
- What it misses: authorization between roles, cross-tenant access through the Fineract-Platform-TenantId header, and maker-checker logic behind authenticated calls.
- Access the client provides: the agreed target hostnames, the rules of engagement, a named contact for emergency stops and written permission to test the production or staging edge.
- Typical cost driver: the number of exposed hostnames and the depth of gateway testing, not the number of business workflows.
- Ask the partner: how they confirm that a finding on the edge actually reaches Fineract's API and not a cached or static page.
Before accepting a black-box result as complete, confirm with your tester which authenticated paths they could not reach and whether those gaps are covered by another approach.
A grey-box test gives the tester working accounts, usually one per role and per tenant, and enough documentation to log in and exercise the workflows. This is the most common approach for Fineract because most of the risk sits behind authentication: loan approval, savings transfers, client records and reports. With accounts for each role in each tenant, the tester can compare what a teller, a loan officer, a checker and a branch manager can each do, and whether one tenant's data can be reached from another. Grey-box testing is usually the best balance of coverage and effort for a production-like environment.
- What it finds well: broken object-level authorization, privilege escalation between roles, tenant isolation failures and maker-checker bypasses.
- What it misses: flaws in code paths no account can reach, hidden configuration weaknesses and secrets stored in images or deployment files.
- Access the client provides: one test account per role per tenant, a role matrix that states what each role should be allowed to do, and API or user guides for the workflows in scope.
- Data handling: test accounts should point to a copy of production data or a seeded environment, as covered in the safe testing guidance for this page.
- Ask the partner: how the role matrix will be used to generate authorization test cases, and what happens to accounts when testing ends.
Confirm that the role matrix was written by someone who owns the business rules, because a tester cannot find a gap between intended and actual permissions without a stated intent.
A white-box test adds source and configuration access, typically the apache/fineract repository at the version you run, any custom modules or forks, and the deployment manifests, environment variables and container images. The tester can read authorization annotations, SQL built from user input, batch job configuration and how profiles and secrets are loaded. This approach finds issues that are hard to see from outside, such as a query that concatenates a search parameter or a configuration path that enables a non-production profile. It is the most thorough approach and the most sensitive, because it exposes how your system is built.
- What it finds well: injection points in search and report code, authorization logic defects, insecure defaults in profiles and environment files, and risks in custom code.
- What it misses: runtime behavior that depends on your data, network placement and gateway rules, which still need black-box or grey-box checks.
- Access the client provides: read access to the exact source revision and any forks, the Kubernetes or Compose manifests with secrets redacted, and a build pipeline record for the deployed images.
- Confidentiality: agree in writing how source and manifests are stored, who may see them and when copies are deleted.
- Ask the partner: how findings will be matched to the exact release you run, since a fix in the project does not reach your deployment until you upgrade or back-port it.
Check that the tester will verify each source-level finding against the running system before reporting it, because code paths can be unreachable in your configuration.
Test scope options and when each fits
This table compares six scope options for a Fineract penetration test, from edge-only work to a full application review with infrastructure. Read each row against the systems you run, the data a tester would reach, and what you can supply before the work starts. The main takeaway is that a narrow scope is cheaper to define but leaves tenant isolation and maker-checker logic untested unless you add them deliberately.
| Scope | What it covers | What the client provides | When it fits |
|---|---|---|---|
| Edge and gateway only | Exposed hostnames, TLS configuration, route allow-lists, WAF rules and rate limits in front of Fineract, plus whether self-service or test endpoints are reachable from outside | Edge architecture diagram, gateway and WAF configuration exports, a list of published routes, and test accounts with no privileges | Early in a project, or when the gateway was just changed and you need to confirm nothing internal is exposed |
| API authorization and tenant isolation | Whether a user in one tenant or office can read or change another's clients, loans and savings, and whether role and permission checks hold on each endpoint group | Tenant list, one test user per tenant and per role, office hierarchy, and written expectations for who may see what | Multi-tenant or multi-office deployments where data separation is a stated control requirement |
| Injection focused on search and report endpoints | Input handling in search, report and data-table endpoints that accept filters, sort fields or free text, tested for SQL injection and related input flaws | Inventory of search and report endpoints, sample request payloads, and confirmation that the test database is a copy | After a Fineract upgrade or patch, or when custom reports or data tables were added |
| Maker-checker workflow testing | Attempts to approve your own requests, skip the checker step, replay approvals, or move a pending transaction through states out of order, across loans, savings and journal entries | Documented approval matrix by role and amount, test users for maker and checker roles, and the expected state transitions | Where segregation of duties is a control you must evidence, or where custom workflows sit on top of standard approvals |
| Full application test including front end | All of the above plus the web front end, session handling, browser-side storage, file uploads for KYC documents, and error and debug output | Front-end build or URL, source access if available, document upload types in use, and a named contact for test-related disruptions | When a customer-facing or staff-facing web app is in production, or when front-end code is custom and not from the vendor |
| Infrastructure and database review | Host and container hardening, network segmentation, database account privileges, secrets placement, backup access and administrative interfaces | Architecture and network diagrams, Kubernetes or VM manifests, database role list, and secrets storage location, read-only access where possible | Before a regulated go-live, or when hosting or database settings changed and no one has reviewed them against the application findings |
Testing injection and maker-checker bypass in Fineract
Injection testing and maker-checker testing both need an agreed test plan before any request is sent. For search and report endpoints, the tester should send controlled, authorized payloads against a non-production copy of the deployment, one parameter at a time, and record how Fineract responds to malformed input: error messages, response timing, row counts and any stack traces. Before testing begins, review the project's security reports page and the patch level of the running build. Fineract has a history of SQL injection fixes, and a deployment that predates a fix can be vulnerable even when its configuration looks sound. The Apache Fineract security reports page is the natural starting point, and the patch tracking topic in this group covers how to map a deployed version to its fixes. Do not restate CVE details in the test report; reference the fixed versions your build actually includes and test those assumptions directly.
Maker-checker testing should cover three cases, each with a named expected result agreed with the client. The first is self-approval: a single user creates an action and then tries to approve it with the same account, which the configuration should reject. The second is an unauthorized role: a user whose permissions allow creation but not approval attempts the approval call directly through the API, not only through the front end. The third is replay and batching: the tester resends a previously captured create request, or places the create and approve steps in one batch request, to check whether the checker step can be skipped. Confirm the maker-checker setting and role-to-permission mapping in the client's own configuration first, because expected behavior depends on how the client enabled approvals and assigned permissions. Record each attempt in the audit trail so the results can be reviewed alongside the command audit.
Safe testing against a copy of production data
This sequence sets up a test environment that resembles production closely enough to find real weaknesses while keeping personal data masked and live payment rails disconnected. Each step ends with a check, so the testing team and the client both know the copy is safe to attack before any test traffic is sent.
Agree rules of engagement in writing
The client and the testing firm sign a rules of engagement document before any environment is touched. It names the in-scope hosts, tenant IDs, API areas and test windows, the accounts the testers may use, the prohibited techniques (for example, denial of service against shared infrastructure), and who approves exceptions. Output: a signed document that both parties keep. Check: every test case in the plan maps to a scope line in that document.
Build an isolated copy from a masked snapshot
The platform team restores a recent production snapshot of the PostgreSQL database into a separate environment, then masks personal and KYC data before testers receive access. The Fineract application stack is deployed from the same release and configuration as production, but on its own network segment with no route back to production databases. Output: a masked copy with a record of what was masked and when. Check: a sample of client, identity and document records shows no original personal values, and the masking job log is retained.
Confirm no live payment or event integrations
Before testing starts, the team checks every outbound connection from the copy. Fineract publishes external business events to ActiveMQ, JMS brokers or Kafka only when this is enabled, and the project's README states that it is disabled by default, so the team confirms that setting in the running configuration rather than assuming it. They also confirm that no payment switch, notification service or document store in the copy points at a live endpoint. Output: a written list of outbound endpoints and their status. Check: a network test from the copy confirms that the only reachable destinations are the test services.
Replace default credentials before testing
The platform team replaces the development login documented in the README and removes any test profile from the copy, so testers do not run against well-known defaults. Tester accounts are created with the roles agreed in the rules of engagement, including separate users for each office or tenant under test and at least one maker and one checker for maker-checker work. Output: a credential register that records account names, roles and owners, kept outside the test environment. Check: a login attempt with the documented default credentials fails.
Set rate limits and test windows
The client and tester agree request rate limits for each target, along with the windows in which intensive scanning, fuzzing and batch-style tests may run. Load-related checks, such as repeated calls to search and report endpoints, are run against the copy only, because the Close of Business batch and read instances can behave differently under sustained load. Output: a test schedule with limits attached to each activity. Check: the gateway or monitoring dashboard shows request rates staying within the agreed ceiling during a short trial run.
Define stop conditions and incident contact
The rules of engagement list the conditions under which testing stops immediately, such as unexpected access to production hosts, data appearing that should have been masked, degraded service in a shared environment, or any sign that a payment or event was sent to a live endpoint. Each condition has a named contact on the client side and a named lead on the testing side, with a call route that works outside business hours if testing runs then. Output: a one-page stop card agreed by both parties. Check: a tabletop run of one stop condition confirms that both contacts receive the alert and can halt the test.
Operational risks to manage during the test
A penetration test against Fineract can damage live books, disturb scheduled batch work and leave credentials or test data behind. The cards below pair each risk with a control the test plan should name before any tester logs in.
Accidental impact on live data
Testers sending write requests, fuzzed payloads or bulk calls can create or alter loans, savings entries and journal postings in a live tenant. Run active testing only against an isolated copy of production data, and confirm that the test environment's connection settings point to that copy and not to the production database or tenant. Ask the tester to name every tenant identifier used in requests, and check the list against the environment before testing begins.
Batch job interference
Close of Business Day runs as a Spring Batch job that can take several hours on large deployments, and it can be partitioned across worker nodes. Fault injection, heavy fuzzing or load tests during that window can slow or break the job and leave accounting in an unclear state. Agree a test calendar that avoids scheduled batch runs, and ask the tester to stop before any scheduled job starts.
Sensitive data in test reports
Evidence such as request and response captures, screenshots and database extracts can contain client names, identity numbers, account numbers and KYC document references even when fields are partly masked. Define in the rules of engagement which data classes may appear in findings, require redaction before reports leave the test team, and store raw captures in an encrypted location with a set retention period agreed with the client.
Leftover test accounts and tenants
Test users, test clients, sample loan products and extra tenants created during the test can persist after the engagement and become a route back into the system. Keep a written inventory of every object the tester creates, including tenant records in the tenants database. Remove or disable those objects after testing, then compare the final state with the inventory and record the result.
Retained tester credentials
Accounts issued to testers, API tokens, OAuth client secrets and VPN or bastion access can outlive the engagement if nobody owns their removal. Issue time-limited, individually named accounts with the fewest roles needed, rotate any shared secrets used during the test, and revoke access on the agreed end date. Confirm the revocation with the client's identity team, since the test team cannot verify it alone.
Questions buyers ask before commissioning a Fineract pentest
What drives the cost of a Fineract penetration test?
The cost follows the written scope, and the main drivers are how many distinct surfaces are in play and how deep each one is tested. A Fineract test can cover the REST API with its tenant header and authorization model, the search and report endpoints, maker-checker workflows, the front end, the API gateway, and the database and batch layers. Each added tenant, each additional role, each integration and each environment to test adds work. Authenticated testing with several role accounts usually takes more effort than unauthenticated testing, and retesting is a separate line item. DeployOpen does not publish a price list, and a quote follows from the scope agreed in writing before work starts. Ask the provider to itemize testing, reporting, retest and any test-environment setup separately.
How long does a Fineract pentest take, and what sets the duration?
Duration depends on the number of surfaces, the number of roles and tenants to test, the state of the test environment, and how quickly the client returns access and answers questions. Testing tends to expand when authorization has many roles, when multiple tenants must be checked for isolation, or when a fix needs to be verified during the engagement. Delays often come from waiting for accounts, a restored copy of production data, or firewall rules that block testers. Ask for a timeline in the written scope that separates preparation, testing, reporting and any retest window, and confirm which of those depend on your team.
What must our team provide before a Fineract test starts?
A test is only as accurate as the inputs. Plan to provide the following before work starts:
- A list of tenants, with their identifiers and the business purpose of each.
- Test accounts for each role that uses the system, including maker and checker roles, with agreed permissions.
- A snapshot or copy of production data, restored into a non-production environment, with personal data handled under your own controls.
- An architecture description covering the gateway, WAF, load balancers, read and write instances, batch instances, database layout and any event brokers.
- Network paths, allowed source addresses and an escalation contact for the test window.
Confirm each item with your own environment owners, since the exact layout varies by deployment.
Can our internal security team run a Fineract pentest without a partner?
Internal teams can test parts of a Fineract deployment, and many do regular checks of their own. The question is whether they have the skills, time and independence for the full scope. Tenant isolation, maker-checker bypass attempts and injection in search and report endpoints need testers who know the Fineract API and its authorization model in depth. Independence also matters, because the team that built or operates the system often has blind spots. A common model is for internal staff to run routine checks and bring in an external tester for a scoped, authenticated assessment. Decide this by comparing skills, independence needs and the evidence your regulators or auditors expect.
How are Fineract pentest findings retested?
Retesting checks whether a reported issue has been fixed in the environment the fix was deployed to. Ask the provider to state in the written scope how many retest rounds are included, which findings are covered, which environment is used, and how evidence of a fix is recorded. Retesting usually needs the same test accounts and access as the original work, so arrange those early. Fixes to Fineract itself may depend on upstream patches or back-ports, so confirm with your team which version you run and whether you carry custom builds or forks that need their own patch process. Retest effort is usually lower than the original test, but it is still a separately scoped line item.
Does a penetration test count as a compliance audit?
No. A penetration test gives evidence about how exposed a system is at the time of testing, and it can support a compliance program. It is not an audit report, an attestation or a certification. DeployOpen runs security testing and prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue audit results. Before commissioning a test, confirm with your auditor or regulator which evidence they accept, what date range it must cover, and whether they want the test performed by an independent party. Ask the provider to structure the report so its findings can be mapped to your control requirements.
What should we ask for in a quote for a Fineract pentest?
Ask for a quote that is built from a written scope and that lists each component separately. Useful items to request include the surfaces covered, the roles and tenants tested, whether testing is authenticated, the test environment and how it is prepared, the reporting format, retest rounds, and any support after the report. Also ask which costs are one-time and which recur if you move to a retainer for ongoing testing. Ask what the provider needs from you, and what happens if scope changes during the engagement. A quote that cannot be traced to a scope document is harder to compare and to govern.
Limits to confirm in your environment
A penetration test is only as useful as its assumptions about the target. Several of the findings depend on settings that vary between deployments, so confirm each item below in writing before the test window opens and record the answers in the rules of engagement.
Fineract version and patch level
Record the exact release and any custom patches or forks in the build. The current stable line is 1.15.0, but many production systems run older 1.x builds, and security fixes are back-ported case by case. Ask the team for the image tag or build artifact, then compare it against the project's security reports page so the testers know which known issues to probe and which to skip.
Self-service APIs enabled or disabled
Confirm whether self-service endpoints are reachable, because they change the attack surface and the expected authorization model. The project advises keeping them disabled. If they are exposed through the gateway or directly, include them in scope with customer-level test accounts and a separate authorization matrix.
Active authentication mode
Establish whether the deployment uses HTTP basic authentication or OAuth2, and whether the default development login was removed. The testers need to know which credential flow to exercise, how tokens are issued and validated, and whether any test or development profile is still active. Ask for the configuration file or environment variables that set these values.
Event publishing to ActiveMQ or Kafka
Event publishing is disabled by default. If it is enabled, business events such as ClientCreated leave the core and reach a broker that has its own access controls, retention and consumers. Testers should check whether broker credentials, topic permissions and consumer groups are protected, and whether a compromised tenant could read another tenant's events.
Front end version in use
Fineract is headless, so the user interface comes from a separate application, such as the Mifos X web app used in the project's Kubernetes example. Ask for the exact front end version, its build source and how it stores session tokens. Front end findings such as cross-site scripting or insecure token storage depend on that version, so they cannot be scoped without it.
Gateway forwarding of tenant headers
Fineract selects the tenant from the Fineract-Platform-TenantId header. Confirm whether the gateway or proxy forwards this header unchanged, strips or overrides it, and whether clients can set it directly. Tenant isolation tests are meaningless if the edge rewrites the header, so ask for a sample request and response that show how the header reaches the application.
What a useful Fineract test report contains
A useful Fineract penetration test report starts with the scope and rules of engagement, because every later finding depends on what was in bounds. The report should list the hosts, the API base paths, the front end and gateway components, and the database and batch systems that were excluded. It should also record the testing windows, the accounts and tenants the testers were allowed to use, whether load or denial-of-service testing was permitted, and who on the client side could stop a test. Ask the testing firm to state these rules in writing before testing begins, and to confirm whether any test ran against a copy of production data rather than live records.
Next, the report should name the tested tenants and roles precisely. Fineract is multi-tenant and requests carry a Fineract-Platform-TenantId header, so a finding about tenant isolation is meaningless unless the report shows which tenants were created for testing, which were the targets, and which user roles were used for each attempt. Each finding should give reproducible steps: the exact request, the headers and parameters changed, the expected behavior, and the observed response. For maker-checker findings, the steps should show the maker and checker accounts separately. Severity should be stated twice, once as the tester's technical rating and once adjusted for your risk context, such as the sensitivity of client KYC documents and the value of the affected products. Evidence containing personal data should be masked in the report, and the report should say how raw captures were stored, who had access, and when they were destroyed.
Finally, the report needs a retest plan. Each finding should have a fix owner, a proposed verification step, and a retest status. Ask the tester to rerun the original steps against the patched build, not a summary of them. DeployOpen prepares findings, reproduction steps and evidence, but an independent auditor issues any audit opinion or attestation, so the report should be written so that an auditor can trace each control to the evidence without needing the tester to interpret it. Confirm with your assessor which format and retention period your compliance program expects.
How DeployOpen scopes and delivers Fineract security testing
DeployOpen is a Chainscore Labs company that runs security testing of self-hosted open-source platforms inside the client's own infrastructure. For a Fineract deployment, we agree a written scope covering the API, tenant isolation, the front end and gateway, and a copy of production data, then deliver findings and retest support in a fixed-scope engagement.
How we scope
- We agree in writing which Fineract environments, tenants, API areas and gateway components are in scope.
- The scope names the test accounts, roles and office hierarchies we will use for authorization and maker-checker testing.
- We confirm rules of engagement, testing windows, and which production-data copy and environment we will test against.
How we build
- We map the API surface, including search and report endpoints, and test authorization and tenant isolation per role.
- We probe injection points in search and report endpoints, and attempt maker-checker bypasses against approval workflows.
- We test the front end and gateway and run the work against a restored copy of production data, not live records.
How we hand over
- We deliver a report with reproduction steps, affected endpoints, severity and recommended fixes for each finding.
- We walk your engineering and security teams through the findings and agree which items need retesting.
- We return test accounts, scripts and evidence to your team so retests and future tests can be repeated.
How we support
- Retesting of agreed findings is included as part of the fixed-scope engagement once fixes are deployed.
- Ongoing testing, upgrades and continuous security testing are available as a retainer after the initial engagement.
- Ask us to confirm the retest window and support terms in the written quote before work starts.
