Services / Continuous Operations
Security Control Validation
You bought the tools. Nobody ever checked whether they are protecting you.
The problem
You have an EDR, a WAF, a cloud security platform, a mail gateway and an MDM. Every dashboard is green. Nobody has ever checked whether the EDR is in monitor-only mode, whether a third of your servers have no agent at all, or whether the WAF has been in count mode since it was installed two years ago. The tools are not the problem. Nobody has ever validated their configuration.
The method.
Connect to the tools you already own, read-only, over their APIs
EDR and XDR consoles, cloud security platforms, WAF and CDN, mail security gateways, MDM, the identity provider, backup platforms, DLP and the SIEM. Read-only API credentials with least-privilege scopes. We are assessing the configuration of your security stack, not adding another tool to it.
Measure coverage against the asset inventory
The first question every tool answers dishonestly: what is it protecting. Agent count versus asset count, per environment and per cloud account. Servers with no EDR, endpoints the MDM never enrolled, cloud accounts outside the security platform, domains outside the WAF, mailboxes outside the mail gateway. The dashboard shows you the machines it can see; we show you the ones it cannot.
Assess enforcement posture, not just deployment
A deployed tool in observation mode protects nothing. EDR: is prevention on or is it monitor-only, are tamper protection and script-blocking enabled, are there exclusion rules that carve out entire directories. WAF: are rules in block mode or count mode, when were they last tuned, is the origin reachable directly, bypassing it. IdP: is conditional access enforced or report-only, are there legacy-auth exemptions. Mail: is DMARC at reject or at none. This step is where most of the findings are.
Test the detection and alert path end to end
A control that detects but does not notify anyone is not a control. We trace the path: does the detection reach the SIEM, does it generate an alert, does the alert reach a human, and is anyone actually on the receiving end. Alert rules that fire into an unmonitored channel, and integrations that broke silently months ago, are found constantly.
Map every finding to the compliance control it breaks
This is the part a security assessment normally omits. EDR in monitor-only is not merely a security weakness. It is a failure of ISO 27001 A.8.7 and of the SOC 2 monitoring criteria, and you attested to it. Every configuration finding carries both its security impact and the specific control, clause and customer attestation it undermines.
Re-validate continuously, because configuration moves
Someone adds an EDR exclusion to fix a build. A WAF rule is set to count mode during an incident and never set back. A new cloud account is created outside the security platform. Configuration drift is measured in days, so validation runs continuously and reports the change against the last known-good state.
What is security control validation?
Security control validation is the assessment of whether the security products an organisation already owns (EDR, WAF, cloud security platform, mail gateway, MDM, identity provider) are configured to actually protect it. It connects to each tool over its API and examines coverage against the real asset inventory, enforcement mode versus observation mode, exclusions and bypasses, and whether detections reach a human. It is not a new security product; it is an assessment of the ones you have.
Why do security tools fail even when the dashboard is green?
Because a dashboard reports on what the tool can see. It shows the endpoints with an agent, not the ones without. It shows blocked traffic, not the origin server reachable directly around the WAF. It reports healthy policies without saying they are in monitor-only mode, or that an exclusion added during a build outage still carves out an entire directory. Green means the tool is running, not that it is protecting you.
Is security control validation the same as API security?
No. API security is about protecting your own application's APIs from attack. Security control validation uses the read-only management APIs of your existing security products to assess how those products are configured: their coverage, their enforcement posture, and whether their alerts reach anyone. The subject is your security stack, not your application.