Cybersecurity and web vulnerability audits

Vulnerability audits, lightweight monitoring and application hardening.

Penetration testing, permission review, API hardening and an incident response plan. The report prioritises by CVSS and by real impact, and includes the breach notification protocol: the GDPR gives you 72 hours to tell the authority.

Who it is for

• Businesses holding personal data under the GDPR
• SaaS vendors whose enterprise clients demand an audit
• Funded startups with public exposure

Why it ends up being needed

Hardly any incident starts with a sophisticated attack. It starts with a library that has not been updated in two years, an API key left in a repository, an account belonging to someone who left and is still active, or an admin panel reachable from the internet because one day someone needed it from home.

What turns that into a serious problem is that it is nearly always found late. With no logs and no alerts, somebody can be inside for weeks; and once it is detected the clock runs: the GDPR gives seventy-two hours to notify a personal data breach to the authority, and that deadline starts when you find out, not when you decide what to do.

So a useful audit does not end with a list of vulnerabilities. It ends with a fix order justified by real impact, with the urgent things already hardened, and with a written procedure for who does what in the first hours. A list without that gets filed and changes nothing.

What I deliver

• Audit report — Vulnerabilities ranked by CVSS, each with a proof of concept.
• Mitigation plan — A roadmap of fixes with the effort estimated.
• Hardening applied — Rules, access policies and a firewall where it applies.
• Response runbook — A documented procedure for when something happens.
• Dependency review — Libraries with known vulnerabilities and the update that closes them.
• Second pass — What you fixed is tested again and signed off in writing.

What is included

• Vulnerability analysis
• Configuration and access review
• A report prioritised by risk
• A follow-up review of the fixes

What gets decided before a line is written

• What gets tested and what does not — The scope is agreed in writing before anything is touched: which systems are in, in which time window, and which tests are out. An audit that takes a service down at peak hour is not an audit, it is an incident you paid for.
• Production or a staging environment — Active testing runs against staging whenever it exists and resembles the real thing. When it does not, what can be done in production is bounded and done in an agreed window. The gap between the two environments is itself a finding for the report.
• How findings are ordered — By CVSS and by real exposure, not by the score alone. A critical flaw in an internal system with no route to the internet does not come before a medium one on the public site, and presenting it the other way round means the least important thing gets fixed first.
• What is fixed here and what later — Hardening that breaks nothing — permissions, policies, headers, dependencies — is applied within the engagement. Anything that means changing the application is handed over prioritised and with estimated effort, so you can plan it. And whatever is fixed gets retested before signing off in writing.

What is not included

• Social engineering or phishing tests against staff, unless contracted separately.
• Fixing the application code: it is delivered prioritised, applied by your team or agreed as development work.
• Continuous monitoring or an on-call service, which is a different contract.
• Certification: this is a technical audit, not the issuing of a certificate.
• Auditing third-party systems without their written authorisation.

What you need to have

• Written authorisation from the owner of the systems to be tested.
• An agreed time window and who to call if something goes down.
• Test accounts with the different roles, so permissions can really be reviewed.
• Knowing what personal data each system handles, to order findings by real impact.

Frequently asked questions

Is this a real audit or an automated scan?

There is automated scanning, but the report is reviewed by hand. A scanner flags hundreds of warnings and most are not exploitable; what you get is the part that is.

How are findings prioritised?

By CVSS and by real impact, with a mitigation plan in order. A critical flaw in a system nobody can reach does not go ahead of a medium one on the public site.

Will you touch production?

Not without agreeing the scope, the time window and the excluded tests in writing first. An audit that takes a service down is not an audit.

How long does it last?

The audit is two weeks: reconnaissance, active testing and a report with a prioritisation meeting. The second pass over the fixes comes afterwards and is included.

What if you find something serious?

You are told immediately, not at the end in the report. If there is any sign it has already been exploited, the first thing is the breach procedure and its deadlines, not carrying on testing.

Is this enough for what an enterprise client asks me for?

It works as a technical audit with a prioritised report and a second pass, which is what is usually asked for. If what they require is a specific certification, that is issued by an accredited body and it gets said before starting.