How a GreySurface test runs.
A tester leads every step, from the scope you agree to the check on your fix. AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.
- POST /api/checkoutThe tester's call: FindingHigh
- GET /search?q=The tester's call: Closed
- OPTIONS /api/*The tester's call: Closed
Your report holds the proved finding only.
Only confirmed findings reach your report.
AI surfaces leads. A tester decides which hold. The rest are closed and left out.
- Surfaced by AI: POST /api/checkoutThe tester's call: FindingHigh, in your report and sent again at the retest.
- Surfaced by AI: GET /search?q=The tester's call: Closed, left out of your report.
- Surfaced by AI: OPTIONS /api/*The tester's call: Closed, left out of your report.
- Lead
- Surfaced by AI. Worth checking, not yet proved.
- Finding
- A lead a tester proved with a working exploit.
- Closed
- A lead that did not hold. It never reaches your report.
From agreed scope to retest, in five steps.
Testing starts once the scope is agreed with you in writing. Each step names who does the work, your part and what you receive.
Recon
In your windowsWe map the hosts, routes and roles in scope and use the product as each kind of user. AI sorts the surface, and the tester picks the leads.
- Who does it
- A tester, with AI sorting the surface
- Your part
- Confirm each test account signs in
- What you get
- Nothing to act on yet
Exploit
In your windowsThe tester works each lead by hand. They replay requests as another role, probe authorisation and business logic, and chain small flaws into one attack path.
- Who does it
- A tester, by hand
- Your part
- Stay reachable through your named contact
- What you get
- Testing inside your windows, with no destructive actions
Prove
In your windowsA lead becomes a finding only when a working exploit shows what it reaches. The tester follows it to the data or action at risk and records each step.
- Who does it
- A tester
- Your part
- Nothing, unless we ask to check a result
- What you get
- Proof of exploit for every finding
Report
Each finding is written up with its proof, the business risk in plain language and a fix. Findings run most serious first, rated Critical, High, Medium or Low.
- Who does it
- A tester, with AI speeding up the write-up
- Your part
- Read the findings and plan the fixes
- What you get
- The report and an executive briefing
Retest
Once your fixes are live, a tester reruns the exploit behind each reported finding. The record shows whether each fix holds.
- Who does it
- A tester
- Your part
- Tell us when the fixes are live
- What you get
- One retest, within 30 days of the report
What the report contains.
Each finding carries its proof, its business risk and a fix. The sample sheet shows each part as your team will read it.
A plain-language report
Written for the engineers who fix and the leaders who fund the fix.
An executive briefing
What to fix first, written for leadership. Included with every test.
The business risk, ranked
Who could exploit it, how easily, and what they would reach.
Proof of exploit
The exact request and response, so your team can replay it.
A fix for each finding
Written for the engineer who makes the change.
Summary for leadership
Fix the checkout price first.
Findings
- Customers can change the price at checkoutHigh
- Who
- Any signed-in customer
- Effort
- Edit one field
- Reach
- Every order you take
- Sessions stay valid after sign-outMedium
Request
POST /api/checkout HTTP/2
Cookie: session=<customer>
{
"cart": "c_2291",
"total": 0.01
}Response
HTTP/2 201 Created{ "order": "o_7731", "charged": 0.01}Fix plan
- Fix firstPrice every order on the serverHigh
- Fix nextEnd sessions on sign-outMedium
After the report: fix, then retest.
Your engineers fix from the proof in the report. At the retest a tester reruns the original exploit, so the record shows the response before and after the fix.
Your engineers fix from the proof and the written fix.
You tell us once the fix is live.
A tester reruns the original exploit and records the response.
The retest sent the request that proved the finding. Before the fix the order went through at the edited price; after it the order is refused.
Four things we need before testing starts.
Together they become the written scope that testing starts from. The checklist covers the small jobs on your side that keep testing on plan.
The scope
The systems to test, and anything to leave alone.
- target
- portal.acme-corp.com
- out of scope
- the payment provider
Test accounts
Accounts for each role we test as.
- accounts
- for each role in scope
Testing windows
When we may test your live systems.
- environment
- live, by default
- windows
- agreed with you
- limits
- no destructive actions
Sign-off and a contact
Written approval, and one named contact on your side.
- sign-off
- in writing
- contact
- one named person
Testing starts once you agree it.
On your side
- Tell your on-call and security teams the windows, so alerts are expected.
- Sign in with each test account and confirm it sees what that role should.
- Tell us about any release planned during the testing windows.
- Send API specs, diagrams or an earlier report if you have them.
- Decide who on your side reads the report and the briefing.
- Set engineering time aside for fixes, so they can be checked in good time.
Do you test live systems?
Yes, by default. We test inside windows agreed with you, with a named contact on your side and no destructive actions.
What happens to leads that do not hold up?
They are closed and left out. Only findings proved with a working exploit reach your report.
Who does the testing?
Testers with blue team, red team and penetration testing experience. AI never decides what counts as a finding; a tester does.
Is a retest included?
Yes. Once your fixes are live, a tester reruns the exploit behind each finding we reported, once, within 30 days of the report.
Do you tell us how to fix each finding?
Yes. Each finding includes a fix written for the engineer who makes the change, and a tester checks it holds once it is live.
How does continuous testing fit our releases?
Continuous testing runs a full test each quarter, with checks between rounds on request as you ship. Each round brings its own report and executive briefing.
What does a clean result mean?
That the paths we tried did not work on the dates we tested. The report states what was in scope and what was not, because no test finds everything.
Which standards is your testing aligned with?
OWASP Top 10, OWASP ASVS, NIST SP 800-115, CWE Top 25 and MITRE ATT&CK. Our testing is aligned with them. None of them certifies us, and we never claim one does.
How is a test priced?
On its scope, after a scoping conversation. We publish no list prices. Tell us what you run and we reply within one business day.