A finding is only useful if someone can fix it on Monday.

Most security reports are built to look thorough. The useful ones are built to be fixed — by a developer who has never met the tester, against a deadline someone else set.

That is the only part of our method that never changes. Everything else follows the threat and the standard. Attackers moved from servers to applications and from applications to APIs, so our testing did too. The frameworks moved on — OWASP published ASVS 5.0 and a new Top 10, NIST added Govern to CSF 2.0, PCI DSS v4.0.1 made its future-dated requirements mandatory — so our reports cite the current editions, by number, every time. We hold the tools loosely and the evidence tightly.

What we hold to

Five things, and we will argue about them.

Test like the attacker, report like the auditor

The testing is adversarial and creative: chaining small issues, abusing business logic, assuming nothing is off-limits that the rules of engagement allow. The reporting is the opposite — precise, reproducible and dull in the best way. Every finding has the exact request that proves it, so nobody has to take our word for anything.

Map every finding to something you already answer to

Your customers ask about SOC 2. Your bank asks about PCI DSS. Your board asks how you compare. So every finding carries its reference — OWASP, ASVS, NIST CSF 2.0, ISO/IEC 27001:2022 Annex A, PCI DSS — and one piece of work produces evidence for all of them, instead of four separate projects that describe the same weakness four ways.

People first, tooling second

Scanners are good at finding what everyone already knows about. The findings that actually expose customer data — one tenant reading another’s records, a limit that can be raced, a workflow step that can be skipped — need a person who understands what the application is for. We automate the obvious so the people can spend their hours on the rest.

Say what it is, including when it is nothing

We do not inflate severities to make a report look busy, and we do not bury real problems under “informational”. If something is technically a finding but irrelevant to you, we say so. If a part of the application held up under testing, we say that too — a clean result is a result, and you paid for it.

Verified closed, not delivered

An engagement is not finished when the report lands. We stay available while your developers fix, review proposed patches when asked, and retest every critical and high finding at no extra charge. The summary letter you show customers reflects what is true after the fix, not what was true before it.

How an engagement runs

Scope, test, fix, verify.

01

Scope

A conversation about what you ship, who is asking for proof, and by when. We agree scope, test accounts, environments and rules of engagement in writing — including what is off-limits and who to call — and fix the price before testing starts.

02

Test

Manual testing guided by the OWASP Web Security Testing Guide and NIST SP 800-115, with daily check-ins. Anything critical is reported the same day, not saved for the report.

03

Fix

The report, walked through live with your team. Each finding has reproduction steps, a CVSS v4.0 score, its framework references and a specific fix. We stay on call while you remediate.

04

Verify

We retest every critical and high finding and issue a summary letter you can share with customers and auditors. For audits, this is the follow-up review against the roadmap.

The frameworks we work to

Current editions, named precisely.

Security standards move. A report citing the 2017 OWASP Top 10 or the pre-2022 ISO 27001 controls tells a careful reader the work is out of date. These are the editions we test and audit against today, and why each one earns its place.

01 OWASP Top 10:2025 The awareness baseline for web application risk. Broken access control is still number one; software supply chain failures and mishandled exceptional conditions are new.
02 OWASP ASVS 5.0 The Application Security Verification Standard — hundreds of testable requirements in three levels. What turns “we tested it” into “we verified these specific controls”.
03 OWASP API Security Top 10 (2023) The API-specific list, led by broken object level authorisation. Essential for any product with a mobile app or a public API.
04 OWASP Web Security Testing Guide The testing methodology itself: how each category of weakness is actually tested, so coverage is repeatable rather than down to one tester’s habits.
05 NIST CSF 2.0 NIST’s Cybersecurity Framework, updated in 2024 with a sixth function, Govern. Our default for giving leadership an honest picture of maturity.
06 NIST SP 800-115 NIST’s technical guide to security testing and assessment, which shapes how we plan, run and report engagements.
07 ISO/IEC 27001:2022 The international standard for an information security management system, with 93 Annex A controls in four themes. Certification is what European and enterprise customers often require.
08 SOC 2 The AICPA attestation over the Trust Services Criteria — security, availability, processing integrity, confidentiality and privacy. Issued by CPA firms; we prepare you for it.
09 PCI DSS v4.0.1 The card industry standard. Its future-dated requirements, including payment-page script controls 6.4.3 and 11.6.1, became mandatory on 31 March 2025.
10 CIS Controls v8.1 Eighteen prioritised controls. Implementation Group 1 is the most practical definition of essential cyber hygiene for a smaller organisation.
11 MITRE ATT&CK A shared vocabulary of real attacker techniques, used to describe attack paths and to check that detection covers how attacks actually happen.
12 CVSS v4.0 The scoring system for severity, released in 2023. We score with it, then explain in plain words what the number means for your environment.
Who this suits

Teams who ship software and have to prove it is safe.

Booking testing windows for next quarter.

Testing time is scheduled in blocks, so the earlier we scope, the more likely we hit your release or audit date. If we are not the right fit, we will tell you that instead of quoting.