What covert testing is
Covert testing is a security exercise in which a simulated attack or policy breach is carried out without warning most of the people who will run into it. A small group, usually the sponsor and the test lead, knows the plan. Everyone else, including the security team and ordinary employees, reacts as they would to the real thing.
The point is to measure what the organization actually does, not what it says it does. Policies, training records, and tool dashboards describe intended behavior, while a covert test shows the gap between the intention and a busy Tuesday afternoon. In an insider threat program it is the practical check on whether the controls and the people around them work.
The target is the whole chain: whether an employee reports a suspicious message, whether a control blocks a transfer, whether insider threat detection raises an alert, and whether someone picks that alert up and acts on it in reasonable time.
How a covert test runs
A covert test is covert only toward the people being tested. Toward the organization's leadership it is the opposite: planned, authorized, and documented. The usual order:
- 1
Authorize in writing
Executives and legal approve the scope, the limits, and the stop conditions before anything starts.
- 2
Design the scenario
Choose a realistic story, such as a mock phishing campaign or a staged transfer of dummy data, and keep it harmless.
- 3
Run without notice
The tester acts while the rest of the organization works as usual, and a trusted contact can stop the test at once.
- 4
Record the response
Note what was blocked, what was detected, who noticed, and how long each step took.
- 5
Debrief and fix
Share the results with everyone involved, close the gaps found, and repeat the scenario later.
Forms of covert testing
Covert testing is a method, not a single technique. The scenario depends on the control being checked, and the same idea reaches from the inbox to the front door. Mock phishing is the most familiar form, and it can imitate targeted variants such as clone phishing.
| Form | What is simulated | What it shows |
|---|---|---|
| Mock phishing | Deceptive emails sent to employees | How many people report the message instead of acting on it |
| Red team exercise | A full attack on systems and people by a hired or internal team | Whether the security team detects and contains it |
| Insider misuse scenario | A staged transfer of dummy sensitive data to a forbidden destination | Whether data controls block or flag the transfer |
| Physical and device tests | Tailgating through a door or a USB drive left on site | Whether staff challenge strangers and report unknown devices |
| Phone social engineering | A caller posing as IT support and asking for access | Whether staff verify the caller before acting |
What a test looks like in Anexet
When the scenario is a data transfer, the proof sits in the detection layer. A dummy file that matches a content rule in a DLP system should appear as an incident with a risk level, and the tester can open it for incident investigation to follow what happened next. In Anexet the Rules tab lists every security rule with its incident count and risk level, so the counter of the rule a test was meant to trigger shows whether it was caught.
Who knows what
The hardest part of a covert test is not technical. Deciding who is told and who is not decides whether the exercise is safe and fair. The fewer people know, the more honest the result, and the more important the paper trail becomes.
| Role | Informed in advance | Part in the test |
|---|---|---|
| Executive sponsorApproves the exercise | Yes | Signs off the scope and the stop conditions |
| Test leadPlans and runs the scenario | Yes | Designs the scenario and records the results |
| HR and legalGuard fairness and law | Yes | Check the plan against labor and privacy rules |
| Security teamDetects and responds | Usually no | Treats the event as real until told otherwise |
| EmployeesTarget of the scenario | No | React as they normally would |
Covert testing is not covert monitoring
The two are easy to confuse because in both someone is not told something. They differ in kind. Covert testing is a planned, time-limited exercise that checks defenses, approved in advance by leadership and closed with a debrief. Covert monitoring means secretly watching employees over time, and many countries allow it only in narrow exceptions.
Ordinary employee monitoring is best run in the open, with a written policy and a clear notice, for example, a consent banner at sign-in. A covert test does not change that. Testers should not read personal messages or collect real employee data, and the debrief should say plainly what was done.
Common mistakes
Most covert tests fail for organizational reasons rather than technical ones:
Never run a covert test without written authorization: without it, the exercise can be treated as a real attack.
- Treating a failure as a verdict on a person: a click on a mock phishing link is a signal about the process, and blame teaches people to hide mistakes.
- No stop condition: a scenario that cannot be halted can interrupt real work or trigger a real emergency response.
- Real data in the scenario: use dummy files and test accounts, never customer or employee data.
- Devices left on site without a record: a removable media test needs a log of every device placed and collected.
- Running it once: a single result ages quickly as people, tools, and rules change.
Where to start
Start small and plain: one scenario, one control, one clear measure. Pick the scenario that worries you most, agree on the measure beforehand, such as how long it takes for the first person to notice, and repeat the test after the fixes. A series of small tests says more over time than one dramatic exercise.
Report results as a property of the system: time to detect, time to respond, and the place where the chain broke, never a list of names.
A control that has never been tested is an assumption. A covert test turns it into a measurement.
Anexet TeamHow Anexet handles this
Anexet does not run covert tests and does not attack anyone: it is the detection layer that such a test checks. The console elements below show whether a scenario was noticed.
Rules and incidents
A security rule records an incident when a transfer matches its condition, and the Rules tab shows the incident count and risk level of every rule.
Status and category
Each incident carries a status, such as False alert or Important incident, and can be given a category, so test incidents can be tagged and reviewed apart from real ones.
From incident to activity
Open user activity on an incident shows what the user did around that moment, which helps trace the whole path of a test action.
Anexet DLP
Learn more