We break in. With permission.
White-hat testing, the authorized kind: we find the way into your systems while it’s still us finding it, then hand you the fix. Nothing is touched without written scope.
We break in. With permission.
White-hat testing, the authorized kind: we find the way into your systems while it’s still us finding it, then hand you the fix. Nothing is touched without written scope.
Cyber and digital security, done the authorized, white-hat way: vulnerability assessments and testing that find the ways into your systems while it's still us doing the finding — and tell you exactly how to close them.
An authorized assessment works through your application surface by surface, raises what it finds with a severity, and then confirms each fix on a retest. This is a recreation of that board — the real one is scoped to a single system you own and have signed off.
Illustration only. The surfaces, findings and severities shown here are simulated in your browser; a real engagement tests one system, under written authorization, and reports privately.
White-hat means one thing before anything technical happens: written authorization, a defined scope, and rules of engagement we both sign. We test the systems you own, or that you are entitled to have tested, and nothing else — no fishing expeditions, no third-party systems swept in, no surprises.
Inside that scope we work the way a real attacker would, methodically rather than with a scanner's checklist: mapping what's actually exposed, then testing authentication, access control, input handling, the API and the configuration behind it. The goal is not a 400-page tool dump — it's the short list of things that genuinely let someone in, each one proven, ranked by how much it matters, and written so your developers can fix it.
Then we retest. A finding isn't closed because you say it is; it's closed because we've confirmed the fix holds. That retest is part of the engagement, not a separate invoice.
This is the part that isn't negotiable, and it's what separates a security partner from a liability. We test only what you own or are demonstrably entitled to have tested, under written authorization that names the scope, the systems, the timing and the limits. If a system belongs to a third party — a payment provider, a host, a platform — that's their authorization to give, not yours, and we'll say so.
Findings are yours and stay confidential. We don't disclose them, trade them, or keep working copies after the engagement closes. Where testing could affect live service, we agree windows and safeguards first. The whole point is to reduce your risk, never to add to it.
The honest version: if what you're asking for is access to a system you can't show you're entitled to test, we're not the people for it — and neither is anyone reputable.
Not a scanner export. A short, proven list of what matters and how to close it.
Every finding proven and rated by real-world impact, with steps to reproduce and a specific fix — written for the developers who'll do the work.
The remediation for each issue, in your stack's terms, plus a working session with your team if you want one. The point is the hole closed, not the hole named.
Once you've fixed things we test again and confirm each issue is genuinely closed and nothing new opened — so “done” means done.
Four stages, and the first one is paperwork for a reason. Nothing technical happens until the scope and authorization are signed.
We agree exactly what's in scope, what's off-limits and when, and sign the authorization and rules of engagement before anything is touched.
Methodical assessment inside that scope, by hand and with tooling, with a line open to you and anything high-impact flagged the moment it's confirmed, not weeks later.
A plain-English report: each finding proven, rated by real-world impact, with the exact steps to reproduce and to fix — written for developers, not auditors.
Support for your team through the fixes if wanted, then a retest that confirms every issue is closed and nothing new was opened.
The questions worth settling first.
Yes — because it's authorized. Testing a system with the owner's written permission, inside an agreed scope, is exactly what penetration testing is. Testing without that permission is not something we'll do, whoever is asking.
If you own it or run it, yes. If it's hosted or built on someone else's platform, parts of it may be theirs to authorize — we'll tell you which, and we scope around it.
The aim is no disruption. Where a test could affect live service we agree a window and safeguards first, and anything genuinely risky is demonstrated safely rather than run for real.
A description of the system, confirmation you're entitled to have it tested, and a signed authorization and scope. For anything deeper than a surface test, access to a staging copy saves time and risk.
A scanner is a starting point, not the work. Automated tools find the obvious; the findings that matter — broken access control, logic flaws, chained issues — come from testing by hand. You get both, with the noise removed.
They're yours and they stay confidential. We don't disclose them or keep working copies after the engagement closes. The report is delivered privately to you.
Tell us what the system is and that you're entitled to have it tested. We'll tell you honestly what kind of engagement it needs before anyone talks about money.
hello@pikotw.com