From first email to a fix that holds.
No black boxes. You always know what we are testing, what we found, and that it is genuinely closed. Our method is built on the recognised standards for security testing and shaped by one goal, which is to reduce your real risk rather than lengthen a report.
What guides every engagement.
Before the first tool runs, these are already fixed. They are the reason a Katiti report can be trusted.
Authorization first
Every target and every technique is agreed in writing before testing begins. We work inside the scope, never outside it.
Evidence-led
Findings are reproduced and proven by a human, not asserted from a scanner. If we cannot demonstrate it, it does not go in the report.
Non-destructive default
We protect the availability of your live systems. Anything with real risk is flagged, scheduled, and signed off first.
Standards-aligned
OWASP, PTES, and NIST SP 800-115 shape the work, and CVSS v4.0 scores it, so your auditors recognise the result.
Five phases, in order.
Each phase has a clear purpose and a clear output. You are never guessing where an engagement stands.
Scope
Targets, rules of engagement, timing, and emergency contacts agreed in writing.
Reconnaissance
We map your attack surface from the outside in, the way an adversary would.
Exploitation
Manual, adversarial testing backed by tooling, going far deeper than any scanner.
Reporting
One document your board and your engineers can both read and act on.
Re-test
We return, confirm every fix landed, and sign it off. Not before.
01Scope and rules of engagement
Every engagement begins on paper. We agree the exact systems in scope, the techniques permitted, the testing window, and the people to call if anything looks wrong. We sign a non-disclosure agreement before any sensitive detail is exchanged. This document protects both sides. It keeps us inside the boundary you set, and it gives your team a clear record of what was authorised and when.
For production systems we agree explicitly what is off-limits, what requires a maintenance window, and how we signal a genuine emergency. Nothing in the engagement happens outside what this document describes.
02Reconnaissance
We build the same picture of your estate that a capable attacker would build before touching it. That means mapping the domains, hosts, services, and technologies that face the internet, understanding how your application is put together, and identifying the paths that carry real value, such as authentication, payments, and administration. Good reconnaissance is what separates a test that hunts the important weaknesses from one that simply rattles every door at random.
03Exploitation and validation
This is where the work is done by hand. Automated tooling has its place for coverage and speed, but the findings that matter, the chained logic flaws, the broken access controls, the trust that should never have been extended, are found by a tester who understands how the application is meant to behave and then makes it behave otherwise. Where we find a weakness, we validate it. We prove the impact safely, capture the evidence, and stop short of anything that would harm data or availability.
A vulnerability scanner reports that a door might be unlocked. A penetration test opens it, shows you what is behind it, and proves it matters. The gap between those two things is the whole point of hiring people rather than renting a tool.
04Reporting
The report is the product. It opens with an executive summary written for decision-makers, stating the overall risk picture and the handful of things that most need funding and attention. It then sets out every finding in full, each with a clear description, a CVSS v4.0 score, the business impact in plain terms, the steps to reproduce it, and a specific, tested recommendation for closing it. A finding without a fix is only half a finding, so we never leave that half out.
05Re-test and sign-off
Once your team has applied the fixes, we come back. We re-test each issue we asked you to close, confirm it is genuinely resolved rather than merely moved, and provide written sign-off. This closed loop is what your regulator and your board want to see. Not a list of problems, but a record of problems found and problems closed.
06Safety and confidentiality
Throughout, we protect the two things you cannot afford to lose, which are the availability of your systems and the confidentiality of what we learn about them. Testing is non-destructive by default. Findings, evidence, and client identity are held in strict confidence during the engagement and after it. When the work is done, sensitive data gathered during testing is handled and retained according to the terms we agreed at the start.
Standards referenced
- OWASP Foundation. Web Security Testing Guide (WSTG).
- OWASP Foundation. API Security Top 10.
- The Penetration Testing Execution Standard. PTES Technical Guidelines.
- National Institute of Standards and Technology. SP 800-115: Technical Guide to Information Security Testing and Assessment.
- FIRST. Common Vulnerability Scoring System (CVSS) v4.0.
- MITRE. ATT&CK Knowledge Base.