Security audits, penetration testing, and continuous vulnerability scanning, run by the developer who has spent 22 years building the kind of systems that get attacked. Start with a free scan that takes about fifteen seconds, then decide how deep you want to go.
Most security reports land on a developer's desk and die there, because whoever wrote them has never had to ship the fix. I have been writing production web applications since 2002, twenty of those years for private and public sector clients, including law enforcement agencies, where a data exposure can mean a case falling apart rather than a bad quarter.
So my reports read differently. Every finding comes with the specific change, in the specific file or setting, that closes it. If you would rather I just fix it, I can do that too, which is not something most testing firms will touch.
Straight answer on credentials: I am not selling you an OSCP badge or a red team. What I sell is twenty-two years of knowing exactly how WordPress, Formidable Forms, PHP applications and modern JavaScript stacks get taken apart, because I have spent those years assembling them. If your insurer or auditor requires a specific certification on the report, tell me up front and I will say so plainly rather than take the work.
Scoped to what you actually run. Most clients start with one or two of these and expand once they see the first report.
A full sweep of your public surface (headers, TLS, DNS and email authentication, exposed files, outdated components), cross-referenced against known vulnerability data and ranked by what actually matters for your site.
Hands-on, OWASP-aligned testing against your real application: authentication and session handling, access control between roles, injection, file upload, and the business-logic flaws that automated tools never find.
The specialty. Plugin and theme inventory against live CVE data, user enumeration, XML-RPC abuse, file permissions, upload handling, and Formidable form and entry permissions, including whether your form data is exposed to the wrong logged-in role.
I read the code. Custom plugins, themes, API handlers and integration glue get reviewed line by line for injection, missing capability checks, unsafe deserialisation, and secrets committed where they should not be.
REST and GraphQL endpoints tested for broken object-level authorization, missing rate limits, over-permissive CORS, token handling, and the classic problem of an endpoint that is only secured by nobody knowing the URL.
What you have exposed beyond the website: open services, admin panels reachable from the internet, DNS and mail configuration, backup endpoints, staging sites left indexed, and cloud storage that was never meant to be public.
An authorized, agreed-in-advance phishing campaign against your own staff, with a short training debrief afterwards. Most breaches start with a person, not a port, and this is the cheapest lesson your team will ever get.
Security is a moving target. A plugin that was clean in March has a published exploit by June. Scheduled re-scans catch new exposures and newly disclosed vulnerabilities in what you already run, and you hear about the serious ones the same day.
The part most firms leave out. I will either hand your team the fix or implement it myself, then re-test to confirm it actually closed, then issue a clean follow-up report you can hand to an auditor, client or insurer.
A lot of this work gets bought because a regulator, an insurer or a customer's procurement team asked a hard question. I write reports with that reader in mind: scope, method, findings, severity, remediation, and a re-test attestation letter when you need one.
I will tell you honestly which frameworks I can support directly and which need an accredited assessor alongside me. Nobody benefits from a report that gets rejected.
The modernised policy published 25 June 2026 pushes agencies from checklist compliance toward continuous risk management, with vulnerability scanning expected on a regular cadence and remediation tracked. Agencies are expected to meet the updated requirements by 1 October 2027. This is the work I already do for criminal justice agencies, including records systems, evidence handling and confidential fund tracking.
If you take card payments, external scanning and periodic application testing are not optional. I can cover the application-layer testing and prepare you for the formal scan.
Technical safeguards and risk analysis for any system touching patient data, including the intake forms and portals that quietly became the front door.
Evidence of periodic testing for your auditor, plus help answering the security questionnaire that is currently holding up a deal.
Insurers increasingly want proof of testing and MFA before they renew, and they price accordingly. A documented assessment is usually cheaper than the premium difference.
No day-rate surprises. You get a written scope and a fixed number; if the scope grows, we agree the change first.
One site or application
About one week
Authenticated, hands-on testing
Two to three weeks
Application, perimeter and people
Three to four weeks
Larger environments, multiple applications, or agencies reselling this to their own clients? Tell me the scope and I will quote it. White-label reporting is available.
An assessment tells you where you stood the day it was run. Then a plugin ships an exploit, a certificate lapses, or somebody publishes a staging site. These plans re-scan on a schedule and tell you when something changes.
For a single brochure site or small business site.
For sites that take bookings, payments or personal data.
For agencies and regulated operations that need the findings closed, not just listed.
Month to month, billed by Square invoice you can pay by card. Cancel any time, no contract and no termination fee. Tell me the sites first; I only invoice once the scope is agreed.
Testing without documented authorization is illegal regardless of intent. This is the sequence, every time, without exception.
You complete the scoping form below. We talk through what is in scope, what is explicitly excluded, and what would count as a serious finding worth stopping for.
You receive a Statement of Work and a Rules of Engagement document covering permitted techniques, testing windows, escalation contacts and a stop condition. Both are signed by someone with authority to approve it. Only then do I touch anything.
Testing runs inside the agreed window. If I find something critical mid-engagement, you hear about it that day rather than in the report three weeks later.
You get an executive summary your board can read, a technical section your developer can act on, and every finding rated with the specific remediation. We walk through it on a call.
Your team fixes it, or I do. Then I verify it, and issue the clean report or attestation letter you can hand to whoever asked.
No, and I would rather say that here than let you find out later. I do not hold OSCP, GPEN or CEH. What I have is twenty-two years of building production web applications, twenty of them across the private and public sector, and a working knowledge of how the stacks I specialize in actually get broken. If your auditor or insurer requires a named certification on the report, say so in the scoping form and I will tell you straight away whether I can help or whether you need an accredited firm.
The free scan on this page cannot. It only makes ordinary read-only requests. For paid engagements, availability is part of the Rules of Engagement: we agree the testing window, agree which techniques are off the table, and agree a stop condition. Denial-of-service testing is excluded by default and only ever run against a staging environment if you specifically ask for it.
For authenticated testing I need test accounts, one per role, created for me and disabled afterwards. Never your personal login, and never a shared administrator password. Credentials are exchanged over an encrypted channel after the engagement is signed, never through a web form. The scoping form below actively rejects submissions that look like they contain a password or key.
An executive summary in plain English, a scope and methodology section, then each finding with a severity rating, evidence of what I saw, the business impact, and the specific remediation. Where a fix involves code or a setting, I name the file or the setting. You also get a re-test section once the fixes land.
Then you get a report that says so, which is exactly what you want to hand to an insurer or a client's procurement team. I do not pad reports with low-severity noise to justify the invoice. You will see the informational items clearly separated from the things that matter.
Yes, and this is the main reason clients pick me over a pure testing firm. Most testers hand you a PDF and leave. I have been shipping the fixes for two decades, so remediation can be part of the same engagement, which usually costs less than the assessment plus a separate developer.
Yes. White-label reporting is available on the Full Engagement and on the Sentinel monitoring plan: your branding, your client relationship, my testing behind it. Tell me how many sites you manage and I will quote the volume.
No. It shows you everything it found. It is limited by what a passive external scan can see at all. It cannot log in, cannot read your code, and cannot test business logic. That is what the paid work is for, and it is a real difference rather than an artificial one.
This is the information I need to quote accurately and to test lawfully. It goes straight to my inbox over an encrypted connection. It is not stored in a database, and it is never shared.
Free external scan
A passive scan cannot log in, read your code, or test whether one user can reach another user's records. That needs a real assessment.