Follow your pentest from scope to retest
Outer Core keeps the scope, findings, conversations and retest results together. You can follow the work while it is happening and speak directly with the tester running it.
Follow the whole engagementFrom scope to report
These are the eight steps you and the tester move through during an engagement.
Define the scope
Tell us what needs testing. Together we agree the systems, access, timing and safety rules.
Review the quote and rules
You review the scope, testing window and price. Nothing begins until you approve them.
Meet your tester
We match the engagement to a tester with relevant experience. One lead tester remains responsible through retesting.
Testing starts
The tester begins inside the approved scope and records confirmed findings in Outer Core.
See confirmed findings
When the tester validates a weakness, you see the evidence, impact and remediation guidance.
Ask questions
Your engineers can ask the tester for context while the work is still fresh.
Fix and retest
When a fix is ready, request a retest. The tester records whether the original proof still works in the tested context.
Download the report
The reviewed report brings the approved scope, methodology, findings and retest results together.
Follow the engagement from the start
Each confirmed vulnerability appears the moment we validate it. Open any finding to see exactly what you get: scored, reproducible, and ready to act on.
- CVSS 3.1 severity, five levels: Critical, High, Medium, Low, Info. Derived from the base metrics, not hand-set.
- The full finding: title, affected targets, CWE, proof of concept, impact, and remediation advice.
- A customer lifecycle you drive: Pending Fix, Ready to Retest, Fixed, with Accepted Risk as a branch.
Findings land where your developers already work.
- Ready to Retest adds an "Awaiting retest" comment and label.
- Fixed closes the issue: "Verified fixed by Outer Core".
- Accepted Risk closes it as not planned. A failed retest reopens it. Each carries a deep link back into Outer Core.
A confirmed finding becomes a GitHub issue automatically, with its severity, evidence and remediation guidance. Comments sync both ways. The finding status and final report remain authoritative in Outer Core.
Findings land where your developers already work
A confirmed finding becomes a GitHub issue automatically, with its severity, evidence and remediation guidance. Comments sync both ways. The finding status and final report remain authoritative in Outer Core.
- Ready to Retest adds an "Awaiting retest" comment and label.
- Fixed closes the issue: "Verified fixed by Outer Core".
- Accepted Risk closes it as not planned. A failed retest reopens it. Each carries a deep link back into Outer Core.
A confirmed finding becomes a GitHub issue automatically, with its severity, evidence and remediation guidance. Comments sync both ways. The finding status and final report remain authoritative in Outer Core.
Talk to the person doing the work.
You reach the tester actually running your engagement, in the platform, while the test runs. A named Lead Tester owns it start to finish. The Communication tab opens once the test is scheduled.
Mentions notify by email. You always see the shared channel, never a tester's internal notes or their email address.
Record what happens after the fix
A retest checks whether the original proof of concept still works in the tested context.
The finding is confirmed and ready for your team to investigate. Move it forward when a fix is ready, or record that you accept the risk.
A tester re-runs the original proof of concept in the tested context and records the result. If it still works, the finding returns to Pending Fix.
The original proof no longer works under the retest conditions. The tester records the result and marks the finding Fixed.
A state you set yourself from Pending Fix, keeping the finding on record without a fix. It is reversible: move it back to Pending Fix whenever you decide to act.
Retesting of remediated findings is free for one year from report delivery. A retest checks the original proof in the tested context.
Not every reader needs every section.
We write every section. You build the report you need. Choose an executive summary, the full technical detail or any combination in between.
The content is written and reviewed by us; you decide what belongs in the PDF.
One fixed PDF, the complete report as a customer receives it.
In the platform you pick sections when the report is built.
What is included in every engagement
A clear scope, a human-led test and a record your team can keep working from.
A human tester leads the engagement, using tools where they help and judgment where it matters.
Each engagement adds findings, fixes and retest results to your security history, helping your team spot recurring weaknesses and track how security changes over time.
Data locality in the EU.
The three feature-backed frameworks. The pentest is the evidence your audit expects; it does not certify you on its own.
Approve the budget once.
Test whenever you need to.
Most teams re-run finance and procurement every time they want a test. With a wallet, you fund testing capacity once, in tester-days, then spend it on any scope, on demand.
Fund once
Set a testing budget once, as a balance of tester-days in your wallet.
Test on demand
Your team spends it on any scope, whenever they need a test. Start in days, not weeks.
Skip the paperwork
No new purchase order and no re-approval for each engagement. The balance is already yours to spend.
Your balance is a hard ceiling. You never spend past what you funded, so there are no surprise bills.
One balance covers every surface we test. Each engagement is scoped to the work it needs, not to a fixed package.
Finance approves and pays once, for the whole balance. One line item, not a PO per test.
See it on your
own systems
Book a scoping call. We agree the surface, match a tester, and go live in a portal you watch from the first finding to the last fix.
Human-led PTaaS, EU data residency, one report, retests free for a year