Every test starts with your signature, not ours
Security testing is only useful when it's controlled, agreed and reviewed. Here's what happens from first call to verified fix.
A website inquiry never authorizes testing. Filling out our contact form, booking a call or sending an email does not give anyone permission to scan or test your systems. Testing starts only after a signed authorization and written scope.
-
1
Written authorization
Someone with authority over the systems signs off on testing. We confirm your organization owns or controls every target. Where systems sit with a cloud or hosting provider, we check whether their permission is needed too.
-
2
Scope and targets
We agree in writing on the systems, sites and identities in scope, the techniques allowed, and anything that's off limits. Exclusions are as important as targets.
-
3
Scheduling
We set a test window that suits your business, name stop contacts on both sides, and agree how to pause immediately if anything unexpected happens.
-
4
Controlled tests
Tests run only against approved targets, only inside the agreed window. Anything that falls outside scope is recorded as not tested rather than attempted.
-
5
Human review
A qualified technical reviewer checks each result, removes false positives and confirms the evidence supports the conclusion. Software can draft. People decide what goes in your report.
-
6
Executive and technical findings
Leadership gets a short summary of what matters and why. Your IT team gets the technical detail, evidence and suggested fixes. Each result is labeled blocked, detected, allowed, inconclusive or not tested.
-
7
Remediation ownership
Your team or IT provider assigns an owner for each fix and makes the change. We help prioritize and answer questions. Keeping testing separate from fixing keeps the results honest.
-
8
Bounded retesting
We retest the agreed fixes within the window set in your scope and report what's resolved, partly resolved or still open. Then the engagement closes, or rolls into a recurring schedule if you've chosen one.
Findings are confidential by default
Test results describe where you're exposed, so we treat them carefully. The specifics are set in each engagement agreement.
- Access limited to the people named for your engagement
- Multi-factor authentication on systems that hold findings
- Reports delivered through a secure channel, not plain email attachments
- Agreed retention periods and deletion when they end
- No customer findings in consumer AI tools
- We never ask for passwords or network details through this website
Straight answers
Is this a vulnerability scan or a penetration test?
Neither label fits everything, so we say exactly what's in scope. A vulnerability scan lists known weaknesses it can see. A network penetration test goes further and tries, under controlled conditions, to show whether those weaknesses can actually be used to move through your environment. The Baseline Assessment is a scoped network test with analyst review. Your statement of work spells out the techniques, targets and limits.
What does control validation measure?
It checks how specific security controls respond to defined, agreed behaviors. For each test, the result is recorded as blocked, detected, allowed, inconclusive or not tested. It tells you how a control behaved in that test, on those systems, at that time. It doesn't certify the control in general.
Does this replace our MSP or our security tools?
No. We're an independent check on how things are working. Your IT provider keeps running and fixing your environment. We test, report and verify fixes, and we're glad to work directly with them.
Can you test our specific tools?
Often, yes, but we confirm it during scoping rather than promising up front. Whether a particular product can be meaningfully tested depends on the technique, your configuration and the testing platform used. If we can't test something properly, we'll say so and mark it as not tested.
Do you use real malware?
No. Endpoint and anti-malware controls are tested with safe simulations of attacker behavior and industry-standard test files that security products are designed to recognize. Nothing we run is designed to damage systems or spread, and every test is listed in the scope you approve.
Can you check whether staff can paste customer data into ChatGPT or Claude?
That's the goal of our planned AI Data Exposure Testing. We'd use synthetic records, such as made-up Social Security numbers and published test card numbers, to see whether your browser, web proxy or data loss prevention controls block, warn or log the paste or upload. We never put real personal data into an AI tool to test it.
Can you guarantee we can't be breached?
No, and you should be wary of anyone who does. Testing gives you evidence about the scenarios and systems we assessed. It shows where you're exposed and whether fixes worked. It can't account for every attacker, technique or future change.
What authorization is required?
Written authorization from someone with the authority to approve testing of the systems involved, plus confirmation that you own or control them. If any systems are hosted by a cloud or third-party provider, their permission may also be needed. We agree on a test window, stop contacts and exclusions before anything runs.
What happens after a finding?
You get the evidence, the likely business impact and a suggested fix. Your team or IT provider assigns an owner and makes the change. Then we run a bounded retest of the agreed fixes and report what's resolved, partly resolved or still open.
Are all services live today?
Not yet. We're starting with scoped pilot assessments. Continuous Validation, Human Risk Testing, Custom Control Validation and AI Data Exposure Testing are planned and depend on the delivery partners we select. We'll tell you plainly what's available when we talk.
See what the output looks like
Browse a fictional sample report with findings, evidence summaries, fixes and a retest.