Compliance
Compliance here connects the security work you already do to the standards you already follow. The CyberOptix CTEM Platform does not define a framework, a control catalogue or a scoring method of its own.
A framework is a published catalog - the thing an auditor cites, or a technical standard you assess against. PCI DSS, SP 800-53, the OWASP Top 10. Every catalog is available to every organization, so seeing one in the list says nothing about whether it applies to you. Adopting one is what does.
What ships
Twelve published catalogs, each read from its publisher's own source:
| Catalog | Classification |
|---|---|
| NIST Cybersecurity Framework 2.0 | Risk-based framework |
| NIST SP 800-53 Rev. 5 | Risk-based framework |
| NIST SP 800-171 Rev. 3 | Risk-based framework |
| DOE Cybersecurity Capability Maturity Model 2.1 | Risk-based framework |
| Microsoft Cloud Security Benchmark | Risk-based framework |
| AWS Foundational Security Best Practices | Risk-based framework |
| PCI Data Security Standard 4.0.1 | Compliance attestation |
| HIPAA Security Rule | Compliance attestation |
| General Data Protection Regulation | Compliance attestation |
| AWS Well-Architected Framework | Technical scoping |
| OWASP Top 10, one catalog per edition | Technical scoping |
| MITRE ATT&CK, one catalog per domain | Threat coverage |
Every control keeps its publisher's identifier, title and text. The CyberOptix CTEM Platform writes none of them. A catalog whose publisher has not been synchronised yet does not appear; nothing is listed that is not loaded.
Classification
Each catalog is classified by what it may feed, and the classification is the line between compliance and everything else:
| Counts toward compliance figures | Raises control importance | |
|---|---|---|
| Compliance attestation (PCI DSS, HIPAA, GDPR) | Yes | No |
| Risk-based framework (NIST, the cloud benchmarks) | Yes | Yes |
| Technical scoping (OWASP Top 10, Well-Architected) | No | No |
| Threat coverage (ATT&CK) | No | No |
A technical or threat catalog can be adopted to scope a technical assessment and to label findings, and findings mapped to it are shown. It is never a compliance attestation: nothing mapped to the OWASP Top 10 or to an ATT&CK technique counts toward a compliance percentage, a regulatory figure or a certification status.
Versions and revisions
Three different things are versioned, and the page shows all three:
- The publication version is the publisher's own: Rev. 5, 4.0.1, the 2021 edition.
- The source version is the machine-readable release the controls were read from: an OSCAL catalog version, a regulation snapshot date.
- The catalog revision is a number that moves only when the catalog's content changes. Every revision is kept whole, so a control can always be read as it was at any revision.
Adopting a framework
Adopting is what puts you in scope for a standard. It is the only thing on this page you change, and it is what every compliance figure is computed over.
| Adopted | In the catalogue | |
|---|---|---|
| Appears in the list | Yes | Yes |
| Counts toward coverage | Yes, if it counts toward compliance figures | No |
| Raises control importance | Yes, if risk-based | No |
| Shows in compliance reporting | Yes, if it counts toward compliance figures | No |
Adopt the ones you are genuinely held to. Adopting everything does not make you more compliant; it only adds controls you are not actually measured against.
An adoption is pinned to a catalog revision. When you adopt, the adoption records the catalog revision published at that moment, and every figure computed for your organization reads the catalog at that revision. A newer revision published later changes what the framework page can show you; it never silently changes what your assessment was computed over. The framework page lets you read the controls at the current revision or at the one you adopted.
Retiring keeps the record. Dropping a framework marks the adoption inactive rather than deleting it, so an assessment run against it last year still resolves at the revision it pinned. Re-adopting later keeps the original adoption date and the original pin, so a gap does not read as a brand new programme.
Adopting and retiring need the org_admin role. Everyone else sees the list read-only.
See Roles and permissions.
How findings reach controls
Every check names the controls its weakness is relevant to, using each publisher's own identifier - "AWS Security Hub S3.1", "NIST SP 800-53 SC-28". When the check raises a finding, those identifiers travel with it, pinned to the catalog revision published at the time, so the mapping can always be read against what the control said when it was made.
That is the whole mechanism. The CyberOptix CTEM Platform does not define controls of its own and does not restate anyone else's in different words, so a control you see beside a finding is one you can look up in your own copy of the standard. A check whose control belongs to a catalog that does not ship names no framework rather than a substitute.
A finding mapped to a control is evidence relevant to that control. It is not a determination that you have failed it - that judgement is yours and your auditor's, and the platform does not make it for you. See Findings, severity, and risk.
Seeing the findings for a framework
Open a framework and it lists the controls your open findings are relevant to, worst first, with how many findings reach each one.
That list is the answer to "which of our findings are relevant to PCI DSS". It is built from what the checks already found - nothing to categorise, no questionnaire, no assessment to complete first.
It is evidence, not a verdict. A control appearing there is one an auditor will want to look at. Whether you have failed it is your determination and your auditor's, and the CyberOptix CTEM Platform does not make it for you - which is why nothing in this section says compliant, non-compliant or audit-ready.
Each control shows how many findings are open against it and how many have been remediated, and clicking one lists them with the catalog revision each mapping was pinned to.
A control with no findings at all is not shown. That means no check raised anything relevant to it; it does not mean the control is met.
The grade on a finding
A posture finding - a control missing or weakly configured rather than an exploitable weakness - carries a Control Deficiency Grade instead of a CVSS score. CVSS describes what an attacker can do, and a control that is simply absent does not, by itself, let anyone do anything.
Three things decide it:
| Importance | How much of what you adopted asks for the control. Computed from your adopted risk-based frameworks, so the same finding is graded differently for a different customer |
| Degradation | Whether the control is absent, partially applied, or present but ineffective |
| Blast radius | Whether it covers a tenant, a service, or one resource |
Each scores 3, 2 or 1; the total bands to a severity. If nothing you adopted asks for the control, the grade is Informational - it is a hardening suggestion for you, not a deficiency. A compliance attestation you adopted makes the finding a deficiency; only a risk-based framework raises how important it is; a technical or threat catalog does neither.
Degradation and blast radius sit on the finding, next to the CVSS environmental metrics, and both are yours to change. Editing one moves the grade, exactly as editing an environmental metric moves a CVSS score. The values a finding starts with come from what the check found, or from its category - a starting point, not a verdict.
The grade is recomputed each time you read it, so adopting a framework today changes how yesterday's findings are graded.
API
The endpoints behind this section are in the API reference.
Next
- Business units - scoping a programme to a team
- Remediation SLA policy - deadlines for what compliance surfaces
- Reports - sending it to someone who does not log in