Methodology
A standards-aligned approach, documented so it can be checked
The same process runs on every engagement, whatever the sector. It is written down here in full because a client, an auditor or a supervisor should be able to see what they are buying before they buy it.
Our approach
INLD engagements are structured around internationally recognised standards rather than a proprietary process. That is a deliberate choice. A methodology that only INLD understands cannot be evaluated by a client's own security team, cannot be compared against a previous provider's work, and gives a regulator nothing to assess it against. Working from published standards means the scope of an engagement, the categories of test performed and the severity assigned to a finding are all referenced to documents that anyone can read.
It also means our results are reproducible. When a finding is scored CVSS 4.0 with the vector published, a second assessor can disagree with a specific metric and say why. When a test case references an identifier from the OWASP Testing Guide, a client can confirm which categories were covered and which were not. Where we depart from a standard — because the client's environment makes a test case inapplicable, or because the rules of engagement prohibit a technique — the report records the departure and the reason rather than leaving a silent gap.
Standards alignment is not certification. INLD does not hold ISO/IEC 27001 certification, CREST membership, PCI QSA status or any other accreditation, and nothing in our documentation should be read as claiming otherwise. What we claim is that the work follows the methodologies named below, and that claim is verifiable from the reports we produce.
Reference documents
Standards we follow
OWASP Testing Guide v4.2
The structural reference for web application testing. Provides the test case taxonomy we work through and the identifiers used to cross-reference findings.
OWASP API Security Top 10
Applied to REST and GraphQL scope. Authorisation categories in particular drive how endpoints are tested with a second set of credentials.
OWASP Mobile Application Security Testing Guide
Used where iOS or Android clients are in scope, covering storage, transport, platform interaction and resilience requirements.
Penetration Testing Execution Standard (PTES)
Provides the engagement lifecycle: pre-engagement interaction, intelligence gathering, threat modelling, exploitation, post-exploitation and reporting.
NIST SP 800-115
Technical Guide to Information Security Testing and Assessment. Frames the assessment as plan, discover, attack and report, which is the structure our documentation follows.
ISO/IEC 27001:2022 controls
Used as a control reference so findings can be mapped to Annex A. Methodology alignment only — INLD is not certified against ISO/IEC 27001 and is not a certification body.
CVSS 4.0
Vulnerability severity scoring. We publish the full vector alongside the score so environmental assumptions can be checked and adjusted.
FATF Recommendations awareness
Applied to digital asset engagements so that findings affecting travel rule data, transaction monitoring or sanctions screening are identified as compliance-relevant, not only technical.
Engagement lifecycle
Seven phases, in order
Phases run sequentially. Where a client requires an interim briefing — a critical finding that cannot wait for the report — it is raised immediately by the agreed escalation path and does not wait for the phase to close.
Scoping and Rules of Engagement
We agree the asset inventory, the boundary of what may be touched, the credentials to be provisioned, the testing constraints and the escalation path, and we record all of it in writing before any traffic is generated. Constraints cover prohibited techniques, rate limits, permitted testing windows and the named contacts on both sides. Where third-party infrastructure is involved, the client confirms it holds the authorisation required to permit testing. This document is the reference point for the whole engagement, and it is the first artefact an auditor or supervisor asks to see.
Reconnaissance and Threat Modelling
Passive and active information gathering establishes the real attack surface: hosts, endpoints, client bundles, third-party integrations, historic infrastructure still reachable, and exposed metadata. That surface is then mapped against the business to produce a threat model — which assets carry value, which actors would want them, and which paths connect the two. The model determines test priority. Time is finite, and an engagement that spends it evenly across all endpoints rather than heavily on the ones that move money produces a worse result.
Vulnerability Identification
Automated scanning with tuned rulesets clears breadth quickly and cheaply. Manual testing then covers what tooling cannot reach: authorisation logic, workflow abuse, chained conditions and anything requiring an understanding of what the application is for. Every candidate finding from either source is reproduced by hand before it enters the report. Unverified scanner output is not a finding, and we do not include it, because a report padded with false positives costs the client more to triage than it saves.
Exploitation and Impact Analysis
Where the rules of engagement authorise it, we produce controlled proof-of-concept evidence to establish real-world impact rather than theoretical severity. Demonstrations are minimal and reversible, and we do not pivot beyond the agreed boundary or exfiltrate production personal data. Timestamps for any action that could surface in the client's monitoring are recorded so their detection team can correlate afterwards. Where our activity produced no alert, that absence is reported as a finding in its own right.
Reporting
Findings are documented with CVSS 4.0 scoring, reproduction steps precise enough for a developer to follow unaided, and supporting evidence. Each finding states the affected component, the conditions required to exploit it, the business consequence and the recommended remediation. Where the CVSS result understates business impact — common with logic flaws — the consequence is stated separately rather than the vector being inflated. The executive summary is written for a board audience and can be circulated without the technical appendix.
Retest and Verification
After remediation, each finding is retested against its original reproduction steps and recorded as resolved, partially resolved or unresolved, with evidence for each outcome. Partial resolution is called out explicitly, because a fix that closes one path while leaving a variant open is a frequent source of repeat incidents. The retest report is issued as a separate document so it can be shared with auditors, partners or supervisors without the original exploitation detail attached.
Post-Engagement Support
We remain available during the remediation window to clarify technical findings, review proposed fixes before they are implemented, and answer questions from the client's auditors or regulators about what was tested and how. Support is bounded in the engagement letter so expectations are clear on both sides. On completion we issue an attestation stating scope, methodology, dates and residual accepted findings — a concise document intended for exactly the audiences that ask for one.
What you receive
Reporting structure
Every engagement produces the same document set, so a client can hand the right artefact to the right audience without editing our work.
- 01
Executive Summary
Five to eight pages, non-technical, board-consumable. States what was tested, what was found, what it means commercially and what happens next.
- 02
Technical Report
Detailed findings with CVSS 4.0 vectors, reproduction steps, screenshots and supporting evidence, ordered by risk.
- 03
Remediation Roadmap
Prioritised by risk and mapped to the CVSS scoring, with implementation effort noted so sequencing decisions can be made against capacity.
- 04
Retest Report
Post-remediation validation recording each finding as resolved, partially resolved or unresolved, with evidence.
- 05
Attestation of Completion
A concise document stating scope, methodology, dates and residual accepted findings, suitable for regulators, auditors and commercial partners.
Independence and confidentiality
INLD is not affiliated with any technology vendor, platform provider, exchange, custodian or licensing intermediary. We do not resell security products, we do not receive referral fees, and we do not hold commercial relationships that would be affected by the content of a report. Where advisory work has previously been provided on a control, any later assessment covering that control declares the fact so a reader can judge the independence of the conclusion.
All engagements operate under a mutual non-disclosure agreement, signed before technical detail is exchanged. Client data encountered during testing is handled on the principle of least exposure: we take the minimum evidence required to demonstrate a finding, we redact personal data in reports, and we do not remove production personal data from the client environment. Where a demonstration would require handling production personal data, we agree a synthetic alternative in advance or record the limitation in the report instead.
Evidence, working notes and reports are retained for a defined period agreed in the engagement letter — normally twelve months, so that a retest or an audit query can be answered — and then securely destroyed. Retention beyond that period happens only at the client's written request. Reports are delivered through an encrypted channel and are not stored with third-party services outside the agreed arrangement.
If a finding indicates an active compromise rather than a latent weakness, we stop testing and notify the named escalation contact immediately. That obligation is written into the rules of engagement, along with the client's own regulatory notification responsibilities, which remain theirs to discharge.
Start with a scoping conversation
Tell us about your environment, regulatory context and timelines. We will tell you what an assessment would realistically involve, before any commitment.