Why most compliance dashboards are misleading
The common pattern is a screen of green ticks against control numbers. The problem is that a tick conflates three completely different situations: a control that was genuinely checked, a control nobody looked at, and a control no automated tool could ever observe. Once those look identical, the dashboard asserts far more than the product actually knows, and the first auditor who asks "how did you verify that" finds out.
SecAI reports eight statuses instead of two, and none of them is "pass". A control is verified evidence, partial evidence, supporting evidence, a failed technical check, manual verification required, not assessed, outside SecAI technical scope, or not applicable to this scope. A reader can always tell which of those they are looking at.
The coverage figure follows the same rule. It measures the share of controls SecAI can technically observe that are backed by evidence it collected. Controls that require human verification stay in the denominator and never count as covered, because they remain work you owe. Controls no host agent could see are removed from the calculation rather than counted as failures. It is not a compliance percentage and the report says so on the first page.
Frameworks SecAI maps to
- UAE Information Assurance Regulation (NESA / SIA / IAR) for entities in the UAE critical information infrastructure programme.
- UAE Personal Data Protection Law (Federal Decree-Law 45 of 2021) for security-of-processing obligations.
- PCI DSS 4.0.1 for the Linux servers inside a cardholder data environment.
- SOX ITGC for the IT general controls behind financial reporting: access, change, operations and security monitoring.
What the evidence actually is
Everything SecAI maps to a control comes from something the agent measured or the platform recorded, not from a questionnaire. Configuration and hardening findings, SSH authentication events, privileged account and sudoers state, file integrity on sensitive paths, installed packages matched to public CVE data, webshell and rootkit indicators, outbound connection anomalies, host clock synchronisation, the incident history and the automated response actions taken, with timestamps.
One observation serves many frameworks. File integrity monitoring on /etc is evidence for a PCI requirement, a SOX ITGC control and a NESA control at the same time, so the checks run once and the mapping layer does the rest. That is why adding a framework does not multiply the work on your servers.
What SecAI cannot see, stated plainly
A host-based agent has hard limits, and pretending otherwise is how compliance tooling gets organisations into trouble. SecAI does not verify that backups complete or restore. It does not confirm multi-factor authentication configuration. It does not locate or classify cardholder data or personal data. It does not verify encryption of data at rest. It does not verify log retention duration or immutability on the host.
Controls that depend on those report as manual verification required or not assessed, never as satisfied. The list is published in the product, next to the list of things SecAI does collect, so you know exactly which parts of the pack you still have to assemble yourself.
Where this fits in a real programme
Compliance is determined by your own controls, policies and assessment. What a monitoring platform contributes is the continuous technical half: evidence that a control was operating on a given date rather than on the day someone took a screenshot, and a record of what happened when it was not.
The practical use is assembling the pack. You run an assessment per framework, export the PDF, and you have a dated, scoped, control-by-control record of what was verified, what failed, and what remains a human task, with the limitations printed above the results rather than in a footnote.