Security and compliance engineering

Application security services are security engineering for web applications: I test applications and their cloud infrastructure the way an attacker would, report what I find with evidence and a fix for each finding, and harden the code so it does what your security and privacy policies promise. It is for SaaS, fintech and health teams in the US, UK, EU, the Gulf, Japan and Korea.

I completed the Google Cybersecurity Specialization. I do engineering, not legal advice: deciding which laws apply to your business is for your counsel, and I work alongside them.

It suits a SaaS company facing its first enterprise security questionnaire, a product handling health or financial data, a team preparing for SOC 2 or ISO 27001 who want the technical gaps found first, and a founder whose app was built quickly, perhaps with AI tools, and now has real users.

It does not replace a formal certification audit. SOC 2 and ISO 27001 need an accredited auditor; I help you get ready for one. It is also not a box-ticking scan: automated tools give breadth, and the findings that matter usually come from manual testing of access control and business logic.

Pick the risk that sounds most like yours; the first sentence of each says where to start.

An app built fast, perhaps with AI tools: start with the security audit and penetration test, which checks the places such apps most often fail, from exposed secrets to missing authorization checks. The 12-point checklist for hardening an AI-built app lists them.

An AI feature that reads documents or uses tools: the main risk is text that steers the model. Prompt injection in RAG and agent systems explains the attacks and the defences that hold, and LLM evals, guardrails and cost control puts those tests into CI.

A privacy law or an opt-out signal: the engineering is making the backend do what the banner and the policy say. US state privacy laws and Global Privacy Control is the guide, and your counsel decides which laws apply to you.

An accessibility law or a conformance request: start with the accessibility audit and remediation, an audit against WCAG 2.2 AA with the fixes in your code. The European Accessibility Act guide covers whether it applies.

A general audit, a security questionnaire or a launch: the security audit and penetration test is the usual first step, and what a penetration test report contains shows the result.

"A customer sent a security questionnaire and we can't answer half of it." "We launch next month and nobody has looked at this from the outside." "The app was built fast and we don't know what it exposes." "Our privacy policy says one thing and our code does another."

In my experience the serious findings cluster in a few places: one user able to read another user's data, secrets committed to a repository, missing rate limits, and cloud permissions far wider than the job needs. Broken access control is the first entry in the OWASP Top 10:2025 for a reason.

You get a scoped test plan with rules of engagement agreed in writing, findings rated by severity with a proof of concept and a fix for each, an infrastructure review covering IAM, network rules, TLS, headers and secrets, a retest after your fixes, and an executive summary you can share with customers and investors.

The security audit and penetration test is the live offer today. The accessibility audit and remediation applies the same audit-then-fix approach to WCAG 2.2. To see what the report itself looks like, read what a penetration test report contains, which walks through a fictional sample finding.

With scoping: the targets, the test accounts, the time windows and what is out of bounds, agreed in writing and priced as a fixed scope. Testing runs against staging where possible; where it must touch production, we agree windows and limits in advance and destructive tests are never run there. I'll sign an NDA before seeing any detail, and findings go only to the people you name.

The regime shapes what the audit pays most attention to. For EU and UK teams it is the GDPR and UK GDPR: security of processing, processor terms and the records that show personal data is protected. For Saudi Arabia it is the Personal Data Protection Law and its rules on transfers outside the Kingdom; for the UAE, the federal law or the DIFC or ADGM regime, depending on where you are established. For Japan and South Korea it is the APPI and PIPA, both with rules on providing personal data overseas. In every case I test the technical measures and document them; confirm which obligations apply with your counsel.