retest.asiaEarly accessGet your report card

Subject 01 — Security

A test,
not a scan.

Testers and controlled agents work the agreed scope; a senior reviewer confirms each finding by hand. Plain language throughout — what it is, why it matters, what to fix first.

Get your report cardSee a sample report

Scope in writingWritten consentRead-only by defaultSigned by a senior reviewer

The finding map

The map we test against.

How your services talk, where your data flows, how an attacker would chain it. A scan works from a list of URLs. We work from the map.

  1. A vendor's script runs on the checkout page.
  2. It reads the session token, which the cookie did not protect.
  3. With the token, it calls the API as the customer.
  4. The API lists a storage bucket — invoices and addresses.

Illustrative chain — not a client resultThis chain is also the finding below.

Six sub-categories

What we look at.

Security carries six sub-categories, the same on every report card. The written scope decides which, and how deep.

Web app pentest

OWASP Top 10

We look for

  • Injection on search, filters and forms — SQL, template, command.
  • Access control: pages and actions a role should not reach.
  • Security headers, cookie flags, and what the error pages leak.

Who tests it

Agents map the routes and testers work the logic by hand. A reviewer confirms each finding.

You geta confirmed findingevidenceimpactpriorityfix plan

API & auth abuse

sessions · tokens · IDOR

We look for

  • Tokens — where they travel, who can read them, what they open.
  • IDOR: one customer's record reached with another customer's id.
  • Rate limits, password reset, session expiry and logout.

Who tests it

Testers work the abuse paths by hand, with agents for volume. A reviewer confirms each finding.

You geta confirmed findingevidenceimpactpriorityfix plan

Cloud & infra config

buckets · headers · TLS · secrets

We look for

  • Buckets and blobs that anyone can list or read.
  • TLS, DNS and headers on every host in the scope.
  • Secrets in repos, images, env files and build logs.

Who tests it

Agents enumerate the exposure and a tester checks each hit. A reviewer confirms each finding.

You geta confirmed findingevidenceimpactpriorityfix plan

Data exposure & privacy

PII · logs · backups

We look for

  • Personal data in logs, analytics events and error reports.
  • Backups and exports — where they sit and who can reach them.
  • What leaves the product through third-party scripts and pixels.

Who tests it

Testers follow the data by hand while agents sweep logs and backups. A reviewer confirms each finding.

You geta confirmed findingevidenceimpactpriorityfix plan

Supply chain

dependencies · CI · third-party scripts

We look for

  • Dependencies with known issues, and whether they are pinned.
  • CI: who can change the build, and with which secrets.
  • Third-party scripts on pages that hold a session.

Who tests it

Agents read the dependency tree and the CI config; a tester checks the scripts. A reviewer confirms each finding.

You geta confirmed findingevidenceimpactpriorityfix plan

AI & LLM attack surface

prompt injection · tool abuse

We look for

  • Prompt injection through user content and retrieved documents.
  • Tool calls — what the model can do, and with whose permissions.
  • Data the model can read that the user cannot.

Who tests it

Testers probe by hand and agents run the variants at volume. A reviewer confirms each finding.

You geta confirmed findingevidenceimpactpriorityfix plan

Anatomy of a finding

How a finding arrives.

You receive every finding laid out like this one. Each names where it sits, severity and evidence, then impact, priority, fix plan and retest. It reads in plain language.

SecurityIllustrative finding — not a client resultSeverity HIGH

Session token readable by a third-party script

Found by agent · confirmed by hand

Where it sits
Web app · checkout · payment step

The session cookie is not marked HttpOnly, and the page loads a vendor's analytics script. That script can read the token.

Severity

The token is the customer's session, and the script runs on every checkout. High.

Evidence

The request and response pair, the script's origin, and a screenshot of the token read from the page. Reproduced on staging.

Impact

Anyone who controls that script, or the CDN it loads from, can act as a logged-in customer. Orders and addresses.

Priority

It sits on the checkout and needs nothing from the attacker but a script change. Fix first.

Fix plan

Mark the session cookie HttpOnly and SameSite. Load the script under a Content Security Policy, and pin its version. Retest after each change.

Retest

The finding stays open on the card until we retest the fix. Then the line reads fixed.

Retest Cybersecurity — the contract

When the report card is not enough.

On the report card, security is a scoped test with confirmed findings. Testers and controlled agents work it; a senior reviewer confirms each one by hand. Retest Cybersecurity is a separate contract — a deeper third-party test of your company, then hands-on fix help. Nothing starts without written consent and approval.

  • Scoped in writing
  • Written consent and approval
  • Separate contract
  • Own timeline
The report card compared with the Retest Cybersecurity contract
QuestionThe report cardRetest Cybersecurity
What it isA scoped security test, graded as one of four subjects. Confirmed findings, a fix plan on each.A deeper third-party test of the company's security, then hands-on help with the fixes.
The fixesA fix plan attached to every finding.A fix plan, then hands-on help with the fixes alongside your team.
ScopeWritten before we start.Written before we start, with its own timeline.
ConsentWritten consent, signed.Written consent and approval from the authorised owner, signed.
AccessStaging by default; read-only on production when the scope says so.The least access the scope requires; credentials rotated after.
Included?Yes — security is Subject 01 on every card.No — a separate contract, quoted on its own.

Will you break production?

Read-only by default; anything destructive runs on staging, with your consent.

  • A one-page consent and an NDA, signed before anyone touches anything.
  • The least access the scope requires, and only for the tested scope.
  • Credentials rotated the minute the test ends. Nothing about your systems kept.

Are the agents a risk?

Agents do test, inside an approved scope that is written before they start. A person reviews what they find.

  • Agents work the approved scope and nothing outside it.
  • A senior reviewer confirms each finding before it reaches you.
  • Found by agent, confirmed by hand — the line under every finding.

Will this satisfy procurement?

If you need a certificate for an auditor, you need an accredited audit. A report card tells you what to fix. It does not certify you.

  • The written scope names what we tested, and what we did not.
  • Every finding carries its evidence — request, response, screenshot.
  • We claim no certification, on the card or anywhere else.

Is this for you

Who, when, where.

Who asks for this, when it makes sense, and where we usually start. The written scope decides where we finish.

Who it's for

  • The founder about to sign a deal where the other side will ask about security.
  • The CTO or engineering lead who owns the product and has never had a third party look at it.
  • The head of product adding AI features who does not yet know where the new surface is.
  • The one engineer who has been “the security person” on top of their real job.
  • The person who was handed a customer's security questionnaire and has to answer it honestly.

When this makes sense

  • Before a launch, a funding round or an enterprise deal — before someone on the other side asks.
  • After an incident, a near-miss, or an audit question nobody could answer cleanly.
  • When you are adding AI features — prompts, retrieval, tool calls — and the attack surface moved.
  • When a customer's security questionnaire lands and the honest answer to “last third-party test?” is “never”.
  • When the last pentest is a PDF on a shared drive and nobody knows which findings were fixed.

Where we test

  • Web apps and APIs — on staging by default; read-only on production only when the scope says so.
  • Auth and sessions: tokens, IDOR, what a logged-in user can reach that they should not.
  • Cloud configuration — buckets, headers, TLS, secrets — wherever they are exposed.
  • Data on the move: logs, backups, third-party scripts, and who can see them there.
  • AI and LLM surfaces — prompt injection, tool abuse — wherever your product talks to a model.
  • Remote, from a small team in Asia; the product can be anywhere. The list above is where we usually start. The written scope decides where we finish.

From brief to report card

How an engagement starts.

  1. You send a brief — a URL and two sentences about what worries you.

  2. We send back a fixed quote, and the number does not move once you accept it. No day rate.

  3. We agree the scope in writing and you sign the consent. Nothing starts before that.

  4. We test, and your report card lands within 72 hours — every finding in plain language, a fix plan attached.

Retest Cybersecurity contracts get their own timeline, in writing, before work starts.

Book a test

Tell us what needs testing.

The scope comes back in writing, and nothing starts until you sign it. A URL and two sentences is enough.

Book a testAsk a scope question

We agree access later, in the written scope. Send no passwords, keys or secrets.

72-hour report cardNDA + written consentSigned by a senior reviewer