Written scope before testing
Assets, roles, environments, exclusions and rules of engagement are agreed and signed by the system owner. An enquiry never authorises testing.
Seven steps. Each one leaves a record.
From the first scoping call to the agreed retest, every step produces something you can keep, share or check.
The engagement, step by step
- 01 · Scope record
Scoping call
We walk through the system, the reason for testing and who needs the result. We ask about roles, tenants, integrations and environments rather than asking for a complete inventory up front.
You provide: A product walkthrough and the requirement behind the test
- 02 · Signed authorisation
Written scope and authorisation
The proposal states assets, roles, test window, rules of engagement, exclusions and retest terms. The owner of the system signs authorisation before any testing begins.
You provide: Sign-off from the system owner
- 03 · Access checklist
Access and test accounts
We confirm test accounts for every in-scope role, environment URLs, API documentation and any allow-listing. Missing access reduces coverage, so we check it before the window opens.
You provide: Accounts per role, environment details, API docs
- 04 · Critical-issue escalation
Testing window
Manual, authenticated testing against the scope record. Anything that looks critical is escalated to your named contact through the route agreed in the rules of engagement, rather than held for the report.
You provide: A contact who can answer questions during testing
- 05 · Report and evidence
Report
Every finding carries evidence, affected roles, a severity rationale and remediation guidance. The summary is written so your client or customer’s reviewer can read it in minutes.
You provide: Who should receive the report
- 06 · Engineer walkthrough
Readout
A walkthrough with the engineers who will fix the issues, findings first. Questions about root cause and remediation approach are answered here.
You provide: The engineers who own the fixes
- 07 · Verification ledger
Retest
Agreed fixes are retested and the verification ledger in the report is updated, so a reviewer can see what was fixed and when. Retest rounds and timing are set in the proposal.
You provide: A list of fixes ready for verification
Principles we hold to
Manual, authenticated testing
Tools help with discovery. Every reported finding is confirmed by hand and backed by evidence your engineers can reproduce.
Evidence over adjectives
Each finding carries a request and response, the affected roles, a severity rationale and a specific fix.
Critical issues escalated early
If something looks critical during testing, your named contact hears about it through the route agreed in the rules of engagement, not only in the report.
Reports for two readers
A summary your client or customer’s reviewer can read in minutes, and detail your engineers can act on.
Agreed fixes retested and recorded
Where the proposal includes a retest, fixes are retested and the verification ledger is updated in a new report version.
The method behind it
All methodology chapters- Scoping and authorisationHow an engagement is bounded before the first request is sent: the scope record, roles and accounts, environments, rules of engagement, signed authorisation, evidence handling and the conditions that stop testing.
- Authentication and sessionsHow sign-in, recovery, multi-factor, federated login, sessions and tokens are tested across every entry point, including the mobile API and the legacy endpoint nobody remembers.
- Authorization and tenant isolationHow we test that every role can do only what it should, and that one customer organisation can never reach another's data, using a role matrix and at least two test tenants.
- Business logic and workflowsHow we test the rules your product enforces: approvals, payments, limits, plans and multi-step workflows that scanners cannot understand.
- API testingHow we test REST and GraphQL APIs against their documentation and their real behaviour: authorization per endpoint, data exposure, mass assignment, rate limits and versions.
- AI application testingHow we assess AI features as part of an application: data and tenant boundaries, retrieval, tool permissions, resilience to untrusted instructions and output handling.
- Reporting and retestHow findings are evidenced, rated and written up, how the readout works, and how fixes are retested and recorded so a reviewer can see what changed.
Questions buyers ask
Who carries out the testing?
The assessment lead and any additional tester are named in your proposal, together with who reviews the report before it is issued. We do not publish team details that have not been confirmed.
Do you test in production?
Usually in a staging environment that matches production. Where production testing is needed, the rules of engagement set limits on timing, data and techniques.
How do you handle our data and credentials?
Test accounts and evidence are handled under the data-handling terms in your proposal. We ask for test accounts, never personal credentials, and we keep evidence to what the report needs.
What happens if you find something serious?
Stop conditions and escalation contacts are agreed in the rules of engagement. Critical issues are escalated to your named contact through that route rather than held for the report.
How many retests are included?
One round on the reported findings in every package: within 60 days for a focused test, 90 days for a product test, and after each window in a release programme.
Can the report be shared with our customer or client?
Yes. The report is written to be shared, and the summary is designed for reviewers. Who receives it is agreed before testing.
Get a fixed quote for your release.
A short form about the product and the deadline. We reply with scoping questions, then a fixed written quote.