Home / Continuous
Continuous Offensive Security Testing
Testing that runs all year against an agreed scope, directed by a consultant with automation carrying the continuous load. This page sets out what runs when, who does what, and where the service stops.
A report starts ageing the day it is issued
A penetration test is a description of one moment. The consultant agrees a scope, tests it over a week or two, and writes up what was true during that window. The report is accurate when you receive it.
Then your environment moves. A team ships a new subdomain for a campaign. A staging host is exposed while someone debugs a deployment. A dependency picks up a published vulnerability. An administrator adds a permission to unblock a release and does not remove it. None of that appears in the report you are holding, because none of it existed when the testing happened.
The gap between tests is where the risk accumulates. If you test once a year, the average exposure has roughly six months to sit there, and the worst case is twelve. That is not a criticism of penetration testing, which remains the right tool for examining a complex application in depth. It is a description of what a point-in-time engagement can and cannot tell you.
The work a testing week cannot finish
Ageing is only half the problem. The other half is that some offensive work is bounded by elapsed time rather than by effort, and a five-day engagement runs out of days before it runs out of work.
Every experienced tester knows this, and it shows up in reports as a line about limited time or partial coverage. It is not a failure of the consultant. You cannot spray a large user base at a safe rate, enumerate a hundred thousand paths, and wait for a deployment, inside one week. So those tasks get sampled, truncated, or dropped, and the report quietly says so.
Continuous testing is mostly a way of buying elapsed time. The same work, allowed to run to the end.
| The task | Why a week is not enough | What changes |
|---|---|---|
| Password spraying | Has to be slow. Spray a large staff directory quickly and you lock accounts out and get noticed, so a safe rate means weeks, not hours. | Runs at a safe rate across the full user base, with your written authorisation. |
| Content and directory discovery | A thorough wordlist against one large application can take days. Across an estate it is arithmetic nobody wins in a week. | Runs to completion, host by host, and repeats as the application changes. |
| Finding assets you forgot | A snapshot finds what exists on the day. The forgotten subdomain appears three weeks later. | Certificate transparency and DNS are watched continuously, so new names surface as they appear. |
| Rate-limited API enumeration | Throttling caps how fast object identifiers can be swept, so authorisation testing across a large identifier space gets sampled instead of covered. | The sweep continues across cycles until the space is actually covered. |
| Blind and time-based injection | Each probe costs seconds of waiting. Confirming a blind path can take hours, and there are many paths. | Slow probing continues in the background rather than competing with the rest of the scope. |
| Waiting for your environment to move | The riskiest change is often the one shipped the week after testing ended. It was not there to test. | Change is the trigger. A new host or a reopened port is tested because it appeared, not because it was on a schedule. |
This is also why the price works. None of the above needs a consultant at a keyboard while it runs. It needs elapsed time, a defined scope, and a consultant to decide what the results mean, which is exactly how the service is built.
What continuous offensive security testing is
Continuous offensive security testing is an emerging category describing the shift from calendar-based penetration testing to always-on validation. Instead of booking a test, you subscribe to testing. The provider holds a current picture of your in-scope assets, tests them repeatedly through the year, and tells you when something changes.
The distinction that matters is between scanning and testing. A vulnerability scanner compares what it finds against a database of signatures and hands you a list of possibilities. Offensive testing tries to use what it finds, and reports what can actually be reached and exploited. Continuous offensive security testing applies the second approach on the cadence of the first.
Two clarifications, because the category is often described loosely. Continuous does not mean unlimited, and it does not mean unattended. Our version is bounded by a defined asset scope and a defined set of monthly deliverables, and a consultant is accountable for every finding we send you.
How TEQNIX delivers it
The service is delivered by human operators and agentic AI working together. Agents provide continuous coverage at a scale and frequency a human team could not sustain. Human consultants direct the testing, perform the work that requires judgement, enforce the boundaries the agents operate within, and validate every finding before it reaches you. The service is never agent-only, and it is never purely manual. Both are always present.
The shorthand: agents for coverage, humans for judgement and control.
What the tooling handles
- Keeps discovery and enumeration running across every in-scope asset
- Surfaces change and new exposure between consultant passes
- Repeats the mechanical checks at a frequency manual work cannot sustain
- Stays inside the scope a consultant has configured
What our consultants do
- Run the testing: reconnaissance, exploitation, and chaining findings into attack paths
- Direct where to look and decide what is worth pursuing
- Define the scope and configure the boundaries the tooling runs within
- Confirm every finding, then write and sign the report
The seven modules
The service is assembled from seven modules. Surface and Perimeter form the base package and are always included: Surface finds what you expose, Perimeter tests what is reachable on it. Nothing else can be scoped honestly until those two are in place. The other five are added or removed independently, and every module is delivered the same way: continuously, hybrid, and validated by a person. There are no tiers and no service levels.
A package is two decisions: which modules you select, and how many assets are in scope. Those are the only two factors that drive the price.
Cadence
Schedules are built per engagement. What suits a single web application and one domain would be wrong for a large estate spread across several cloud accounts, so yours is set during onboarding, agreed in writing, and recorded in the service agreement.
The shape of it is consistent. The service runs in two layers.
The scheduled layer runs on fixed intervals and does the same checks every time, so that results are comparable across the year and change is obvious. Discovery and exposure checks run most frequently, because they are how new assets and new openings get noticed. Deeper module work runs less frequently and on a defined rotation.
The exploratory layer follows what the scheduled layer finds. When something interesting appears, a consultant directs effort towards it rather than waiting for the next interval. Because that layer is not fixed, depth of coverage varies between cycles.
Reporting is monthly regardless of which modules you select.
Severity and notification
Findings are rated using CVSS v3.1, with business context applied by the consultant who validated them. A textbook high-severity issue on a host with no sensitive data and no onward access is not treated the same as a moderate issue on a path into your customer database, and the rating we give you reflects that judgement rather than the raw score alone.
| Severity | How you are told |
|---|---|
| Critical | Notified within 1 business day of validation, outside the reporting cycle |
| High | Notified within 1 business day of validation, outside the reporting cycle |
| Medium | Included in the monthly report |
| Low | Included in the monthly report |
| Informational | Included in the monthly report |
This is not a monitored service. If you need round-the-clock detection and response, that is a different type of provider, and we will point you towards one.
Validation
Findings come from both the automated layer and the consultant's own testing. Whatever the source, nothing reaches you until a consultant has reproduced or confirmed it.
In practice this means one of two things. Either the consultant reproduces the issue themselves and records how, or, where reproducing it would be destructive or disruptive, the consultant confirms the evidence and says explicitly in the finding that it was confirmed rather than re-executed. You can tell which happened from the finding itself.
The reason is practical. Automated output includes false positives, and forwarding a list of maybes would move our work onto your desk. Validation is the part of the service a consultant is paid for.
Guardrails
Human oversight here is a safety control as well as a quality control. An agent that can test can also reach the wrong target or act destructively, so consultants set the boundaries and those boundaries are enforced technically rather than by instruction.
- Scope is enforced at the network layer, not by instruction. Out-of-scope targets cannot be reached.
- Destructive actions, denial-of-service and credential attacks are blocked by default.
- Every command an agent runs is logged, and those logs are available to you on request.
- A consultant reviews agent activity as part of each reporting cycle.
- Domain ownership and written authorisation are verified manually before any testing begins. There is no self-serve path.
What this service is not
- It complements deep point-in-time testing rather than replacing it. A complex application with unusual business logic still benefits from a consultant spending uninterrupted time inside it, which is what our penetration testing engagements are for.
- It is not intrusion detection. We test your exposure; we do not watch for attackers in your network.
- It is not incident response. If you are compromised, you need a responder engaged immediately.
- It does not remediate findings. We report them, explain them, and verify your fixes.
- It is not a guarantee against compromise. It shortens the time an exposure goes unnoticed, which is a different and more honest claim.
What it costs, against the alternative
The base package covers Surface and Perimeter for $10,000 a year, billed annually. That is roughly what an annual external penetration test costs, for one week of coverage instead of a year of it.
| Measure | Annual external penetration test | Continuous — base package |
|---|---|---|
| Testing days per year | About 5 | 365 |
| Time to learn about a new exposure | Up to 12 months | 1 business day |
| Covers assets deployed after testing began | No | Yes |
| Report accuracy | Accurate on the day it was issued | Current |
| Tasks that take weeks to finish, such as password spraying and content discovery | Rarely completed inside a one-week test | Run to completion |
| Cost | About $10,000 a year | About $10,000 a year |
A penetration test tells you what was true in March. This tells you what’s true today.
How to start
Four steps, and the first two are ours.
We talk through what you have exposed and which modules make sense, then we verify domain ownership and take written authorisation along with a confirmed asset register. Nothing is tested before that is in place. Once it is, we build your schedule, agree it in writing, and begin. Your first monthly report follows the first full cycle, and you have portal access from the start.
There is no self-serve signup. Pointing testing tools at infrastructure requires confirming that whoever requested it is entitled to authorise it.