Every TigerGate cloud / Kubernetes finding carries a framework_refs map that ties it to the control IDs it fails in each framework, for example {"CIS-3.0": ["1.20"], "PCI-DSS-4.0": ["6.5.7"], "SOC2": ["CC6.1"]}. Runtime compliance controls and their ESRs carry an equivalent list of framework tags. The platform rolls these into per-framework scorecards you can drill into and export.

​
Supported frameworks

Industry standards: CIS Benchmarks (AWS / Azure / GCP / OCI / K8s / Docker) · NIST 800-53 · NIST CSF · ISO 27001 · CIS Controls v8 Regulatory: PCI DSS 3.2.1 / 4.0 · HIPAA Security Rule · GDPR · SOC 2 Type II · FedRAMP · FFIEC · GLBA Cloud-specific: AWS Well-Architected · AWS Foundational Technical Review (FTR) · Azure Security Benchmark · GCP Security Best Practices National: ENS (Spain) · RBI (India) · APRA (Australia) Governance: SOX · COBIT · COSO · HITRUST CSF

​
How findings get tagged

Each scanner contributes its own framework tags:
SourceExamples of tags
SAST rulesOWASP-A03:2021, CWE-89, PCI:6.5.1, SOC2:CC7.1
SCA findingsCWE-1104, NIST:SI-2, ISO27001:A.12.6
Cloud postureCIS-3.0:1.20, PCI-DSS-4.0:8.4, HIPAA:164.312(a)(2)(i)
Container CVEsCWE-1104, CIS-Docker:5.4
Runtime ESRsSOC2:CC6.7, PCI:10.2, HIPAA:164.312(b)
Tags are additive — one finding usually carries multiple. A SQL-injection finding in a PCI-scope app will show OWASP-A03:2021, CWE-89, PCI:6.5.1, and SOC2:CC7.1 all at once.

​
Scorecards

Cloud Security → Compliance shows one row per framework with a severity-weighted score: 
score = 100 · (1 − weighted_open / max_penalty)

weighted_open = critical*4 + high*3 + medium*2 + low*1
max_penalty   = total_findings * 4
Reasoning:
  • Resolving a critical lifts the score 4× more than resolving a low — matches operator intuition.
  • Severity-weighted (rather than pass/fail-rate) is the only honest score we can compute, because TigerGate stores failed checks; passing checks aren’t ingested. See Cloud Security overview → Scoring model.
Click any framework row to drill into per-control evidence.

​
Per-control drill-down

Click a framework row to open its control breakdown (Cloud Security → Compliance → <framework>). Each row is a control that has findings, showing:
  • Control ID — the framework control (e.g. CIS 1.20, PCI-DSS 6.5.7), which links through to the findings filtered to that framework.
  • Checks — the underlying check IDs that map to this control.
  • Total / Open / Critical / High — finding counts for the control, sorted by open criticals.
Runtime compliance controls have their own detail view under Compliance → Controls → <control>, which shows the control’s category, framework tags, compliance score, monitored-host count, and recent runtime events.

​
Exports

Generate a report from Cloud Security → Reports. Pick a report type, scope it (provider / account / severity / frameworks), choose a format, then either download it or have it emailed.
Report typeContents
CompliancePer-control compliance status across selected frameworks, with pass/fail and failing-finding counts
Cloud FindingsDetailed findings with check IDs, severity, affected resources, regions, and remediation guidance
Asset InventoryCloud resources with posture score and per-severity finding counts
Attack PathsResources grouped by risk concentration
Executive SummaryRisk score, severity tiles, and provider / account breakdown
Full Cloud Security AuditFindings + compliance + assets + attack paths in a single document
Formats: PDF, HTML (print-to-PDF ready), CSV, JSON. The optional framework filter accepts CIS-3.0, PCI-DSS-4.0, HIPAA, SOC2, ISO-27001, NIST-800-53, GDPR, and FedRAMP — leave it empty to include every framework present in the scan results.

​
Continuous compliance vs point-in-time

Two modes per framework:
  • Point-in-time — score reflects findings at the moment you ran the scan / generated the report.
  • Continuous — score is computed over a rolling window (default 30 days). Useful for runtime-evidence-heavy frameworks (SOC 2 CC6.7 — “is access logged?”) where one-off snapshots miss occasional gaps.
Default mode: continuous for runtime-bound controls, point-in-time for cloud-posture controls.

​
Tag a repo / asset to a specific scope

If only some of your fleet is in PCI scope, tag those resources:
  • Repos — Code Security → Repositories → \<repo\> → Tags → +pci
  • Cloud accounts — Cloud Security → Accounts → \<account\> → Tags → +pci
  • Container images — Container Security → Images → \<image\> → Tags → +pci
Then filter the framework scorecard by the tag — the score is computed only over +pci-tagged resources.

​
Framework selection per scan

Scans and schedules can target specific frameworks. On a schedule (Cloud Security → Schedules), pick the frameworks to run from the provider’s framework chips; leaving the selection empty runs every framework the provider supports. Framework tokens are provider-suffixed: 
aws:        cis_3.0_aws · pci_4.0_aws · soc2_aws · nist_800_53_revision_5_aws · aws_foundational_security_best_practices_aws
azure:      cis_2.1_azure · pci_4.0_azure · soc2_azure
gcp:        cis_3.0_gcp · pci_4.0_gcp · soc2_gcp
oci:        cis_2.0_oci
kubernetes: cis_1.10_kubernetes
github:     cis_1.0_github
Narrowing the framework set reduces scan scope when you only care about a couple of frameworks.

​
Custom frameworks

For internal-only frameworks (e.g. your own security baseline), define one from the dashboard at Compliance → Frameworks → New custom framework. The editor takes:
FieldNotes
IDStable slug — acme-platform-v1. Used everywhere the framework is referenced.
NameDisplay name in the Compliance list.
DescriptionFree-form context.
ControlsList of (id, title, maps_to[]) rows. maps_to accepts SAST rule IDs (sast:G409), cloud check IDs (cloud:s3_bucket_encryption_enabled), runtime control IDs (runtime:C2), or any other rule the platform knows about. The dashboard’s typeahead helps pick from the catalog.
A worked example:
IDTitleMaps to
ACME-1Production deploys require code reviewcloud:cloudtrail_no_admin_actions_outside_business_hours
ACME-2Customer data is encrypted at restcloud:s3_bucket_encryption_enabled, cloud:rds_encryption_enabled, cloud:ebs_encryption_enabled
Hit Validate to check that every maps_to ID resolves to a known rule, then Save. The custom framework appears in the Compliance list alongside the built-ins on the next page load. Authoring is UI-only — there is no curl / API for creating or editing custom frameworks.