Grc Compliance Standards

Governance, risk and compliance (GRC) standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies when designing, implementing, auditing or reviewing:

• ISMS ISO/IEC 27001:2022: scope, clauses 4-10, Annex A, Statement of Applicability (SoA).
• Risk management: methodology, scales, risk register, treatment, formal acceptance and exceptions with an expiry date.
• Frameworks and regulation: NIST CSF 2.0, CIS Controls v8.1, SOC 2, ENS (RD 311/2022), NIS2, DORA, CRA, ISO 27701/42001 — scope, obligations and deadlines.
• Evidence and continuous compliance: automatable control→evidence mapping, OSCAL, retention policy, internal and external audit preparation.
• Third-party risk (TPRM): supplier tiering, SIG/CAIQ/CSA STAR, contractual clauses, DORA register of information.
• Document hierarchy: policy, standards, procedures, records; owners and cadences.

Not applicable: see vulnerability-management-standards (for CVE/CVSS/EPSS/KEV triage, patching SLAs and VEX — here only the formal acceptance of residual risk), appsec-standards (for threat modelling and OWASP/ASVS), sre-practice-standards (for SLOs, on-call and postmortems), identity-access-management-standards (for technical IAM), cicd-standards, iac-standards, kubernetes-standards, onprem-standards and the cloud skills (for the concrete controls: the framework, the risk and the evidence live here, not the implementation). Engineering GDPR (DPIA as a technical artifact, minimisation in the schema, retention implemented as deletion, data subject rights as functionality, transfers by design, PII in telemetry) belongs to privacy-engineering-standards: here only the management part (ISO 27701 as a PIMS, RoPA as a register, risk acceptance, audit evidence). Continuity: the management system (ISO 22301, policy, scope, audit) belongs here; the plan and its engineering (BIA, RTO/RPO, recovery order, DR exercises) belongs to bcdr-standards. Incident handling and the technical investigation belong to incident-management-standards and incident-response-forensics-standards; the authorised offensive exercise, to offensive-security-standards. enterprise-architecture-standards (the control framework, the risk register and the audit evidence belong here; the application inventory with its owner, criticality and lifecycle is theirs — and it is the source that feeds the scope of almost every control. A control whose scope cannot be enumerated is not auditable), opensource-licensing-standards (the corporate regulatory obligation and its evidence belong here; the licence policy, the gate and the exception process are theirs), govtech-eidas-standards (reciprocal, already declared from their side: the eIDAS regime — advanced versus qualified signature, qualified provider and trust lists, timestamping, AdES and long-term preservation, electronic case file — and the obligations of Spanish administrative procedure are theirs; the ENS as a management framework — Statement of Applicability, categorisation, certification audit, risk register and the relationship with the CCN — belongs here. Rule: if the question is what legal value what you sign has, it is theirs; if it is which control it evidences and with what evidence, it is ours), accessibility-standards (boundary with a real legal obligation: the applicable regulatory framework, the evidence register and the management of sanction risk belong here; the accessibility statement — its content, its testing and who signs it — is theirs (§6.1), and this document only requires it as evidence — European Accessibility Act, EN 301 549, Ley 11/2023 and its implementing rules, ADA Title II —; the technical conformance criteria — which WCAG criterion is met, how it is tested and what automates it — are theirs. Warning both share: a new version of WCAG or of EN 301 549 does not by itself change the legal obligation, which is anchored to the standard cited in the law).

2. Default decisions

Verify the latest version on the web before pinning it in a real project (§8).

Regulation with dates (status Aug 2026, verify §8):

• DORA (Regulation (EU) 2022/2554): applicable since 17 Jan 2025. The ESAs designated the first 19 critical ICT providers (CTPPs) on 18 Nov 2025 (hyperscalers and large SaaS), under direct oversight with periodic penalty payments of up to 1% of average daily worldwide turnover. As a regulation, it applies directly: it does not depend on transposition.
• NIS2 (Directive (EU) 2022/2555): transposition deadline expired on 17 Oct 2024. Spain still has not transposed it as of Aug 2026: the draft Ley de Coordinación y Gobernanza de la Ciberseguridad (Council of Ministers, 14 Jan 2025) is still in progress; the Commission issued a reasoned opinion on 7 May 2025 and a second request on 19 May 2026 (INFR(2024)0270). RDL 7/2025 partially transposed it for the electricity sector. Art. 23: early warning 24 h, notification 72 h, final report 1 month. Art. 34: minimum fines of €10M or 2% of worldwide turnover (essential) and €7M or 1.4% (important) — these are floors, Member States may raise them. Art. 20: approval and mandatory training of the management body, with personal liability and possible temporary disqualification.
• CRA (Regulation (EU) 2024/2847): reporting obligations from 11 Sep 2026 (early warning 24 h, notification 72 h, final report 14 days/1 month, via the Single Reporting Platform); full application on 11 Dec 2027. It covers a product already on the market if it remains available after Sep 2026.

3. Structure and conventions

Document hierarchy (4 levels, no more): Security policy (1 document, approved by the board, the "what" and the "who is accountable") → Standards per domain (the "what must be complied with", measurable) → Procedures (the "how", with an operational owner) → Records/evidence (the proof). Every document: named owner, version, approval date, approver and next review date. A document without an owner is dead.

Source of truth = internal control catalogue, not the frameworks. Every control has its own stable ID; the frameworks are views that point to it. The other way round (one file per standard) duplicates the work and they contradict each other. Versioned in git, reviewable by PR:

# controls/CTRL-014.yaml — one control, N frameworks, N pieces of evidence
id: CTRL-014
nombre: Review and approval of production changes
dueño: jefatura-plataforma          # accountable for it OPERATING
frecuencia: continua
implementacion: "Mandatory PR + 1 approval other than the author + green CI"
mapeos:                              # one piece of evidence serves several standards
  iso27001_2022: [A.8.32]
  nist_csf_2_0:  [PR.PS-06]
  cis_v8_1:      ["4.1"]
  soc2_tsc:      [CC8.1]
  ens_rd311:     [op.exp.5]
evidencia:
  tipo: automatizada                 # automatizada | manual — the % is measured
  fuente: "Forge API: PRs merged without approval in the period"
  consulta: "scripts/evidence/prs_sin_aprobacion.py"
  periodicidad: mensual
  retencion: 24m
prueba_eficacia: "Sample over the full period; 0 unjustified exceptions"

Risk register — mandatory fields (if one is missing, the risk is not managed): ID · scenario in source → event → consequence format (not "a hack") · affected process/asset · risk owner (business, named, with authority to accept; different from the control owner) · likelihood and impact on the defined scale · inherent risk · existing controls · residual risk · decision (mitigate/transfer/avoid/accept) · plan with an owner and a date · next review date · link to the evidence.

SoA — the document auditors look at most. The 93 Annex A controls, each with: applicable yes/no, explicit justification for inclusion and for exclusion, implementation status, reference to the internal control (CTRL-xxx) and to the evidence. It is updated on every material change to the scope or to the risks, not once a year before the audit.

Exceptions and risk acceptance: a single form with the associated risk, compensating controls, mandatory expiry date (max. 12 months), approver according to the risk level (written authority matrix: who may accept what) and review on expiry. An exception with no date is an undocumented architecture decision.

4. Quality gates and continuous compliance

In increasing order of cost; the first three are automatic and break the pipeline:

1. Policy as code in CI: OPA/Conftest, Kyverno or equivalent over IaC and manifests; IaC and image scanning, SBOM and secret scanning. A critical finding breaks the build — and the signed, timestamped output of the gate IS the evidence, not a screenshot taken afterwards.
2. Scheduled evidence collection: every control with evidencia.tipo: automatizada generates its artifact at its frequency, with a timestamp, traceable origin and verifiable integrity (hash), in storage with retention and restricted access.
3. Coverage dashboard: controls with no evidence within their window = open finding, just like a broken test. Without a dashboard, "we comply" is an opinion.
4. Internal audit (clause 9.3 and annual programme): planned by risk, not by checklist; findings with root cause, plan, owner and date; follow-up until verified closure.
5. External audit / SOC 2 Type II: requires evidence throughout the whole observation period and auditor sampling. A bulk collection the week before is a finding, not preparation.

Design vs. operation: proving that the control exists (design effectiveness) does not prove that it works (operating effectiveness). For each control, define in advance what sample and what deviation threshold count as a failure.

5. Security of the compliance programme

• Evidence is sensitive data: minimise it (redact secrets, credentials, PII, internal IPs if they add nothing), control access to the evidence repository, encrypt it and define retention. A badly protected evidence repository is a map of the organisation for an attacker.
• Segregation of duties: whoever operates a control does not approve their own evidence; internal audit with real independence from the audited function.
• Third parties (TPRM): tiering by criticality and by data access, with a differentiated cadence (critical: full annual review + continuous monitoring; low risk: 24-36 months). CAIQ questionnaires (CSA, aligned with CCM; STAR Level 1 self-assessment, Level 2 attestation) for SaaS/cloud and SIG (Shared Assessments, ~21 domains; SIG Lite for screening) for the rest. When you receive a supplier's SOC 2 or ISO: read the scope, the period and the exceptions — a certificate whose scope you have not read says nothing. Contract with a right to audit, incident notification with deadlines aligned to yours (if you are held to 24 h, your supplier cannot give you 72), subprocessors and exit/portability. In financial entities, the DORA register of information.
• Regulatory deadlines live in the incident response plan, not in a compliance document: the NIS2/CRA 24 h clock starts on becoming aware, and if personal data is involved it runs in parallel with the data protection one.

6. Programme operability

Metrics reported to the board (signal, not vanity): % of controls with automated evidence · average age of the evidence · open findings by age and severity · exceptions in force and expired without review · risks above the declared appetite · % of critical suppliers reviewed on time · mean time to close a finding. The trend matters more than the absolute value.

Minimum cadence: risk register review quarterly (critical) / annual (the rest) · management review annually with the clause 9.3 inputs and outputs · internal audit annually · SoA on every material change · quarterly regulatory radar (§8).

Translation between frameworks — the real saving is here. A single well-defined piece of evidence covers N standards: the change approval record serves ISO A.8.32, SOC 2 CC8.1, CIS 4.x, ENS op.exp.5 and CSF PR.PS-06 simultaneously. Keep the mappings in the control catalogue (§3) and use the official informative references (NIST CPRT for CSF 2.0, mappings published by CIS, Annex B of 27002:2022) instead of inventing them. When a mapping is partial, note it as partial: an optimistic mapping is discovered in the audit, not before.

7. Sustainability and prohibitions

Lifecycle: put dated standards transitions in the calendar of the year they are announced (ISO 27001:2013 → 2022 closed on 31 Oct 2025; 27701:2019 → 2025 closes in Oct 2028). Amd 1:2024 to 27001 requires the determination on climate change in the context to be recorded, even if the conclusion is "not relevant": the auditor asks for it directly.

FORBIDDEN

• ❌ Compliance theatre: template policies never adapted, procedures nobody executes, described controls that do not exist. It is document fraud with pretty formatting.
• ❌ An SoA with everything marked "applicable", or exclusions with no written justification.
• ❌ Risks with no named owner, or with the control owner as the risk owner.
• ❌ Verbal risk acceptance, by stray email, or signed by someone without authority under the matrix. Without a signature with name, date and expiry, the risk is not accepted: it is ignored.
• ❌ Perpetual exceptions, or ones renewed automatically without re-assessing the risk.
• ❌ Fabricated, backdated evidence, or evidence collected only before the audit; a screenshot as the only evidence of a control the tool can export via API.
• ❌ Certifying an artificially trimmed scope so it comes out cheap and selling it as full coverage of the organisation.
• ❌ Confusing the CSF 2.0 Tiers with maturity levels, or the SOC 2 points of focus with mandatory requirements.
• ❌ Delegating the NIS2 management body responsibility (art. 20) to a supplier: it is non-delegable.
• ❌ Assuming that "since Spain has not transposed NIS2, there is nothing to do": DORA and the CRA are directly applicable regulations, contracts and customers already require NIS2, and the law will arrive with short registration deadlines.
• ❌ Sending questionnaires to suppliers and reading neither the answers nor the attached evidence.
• ❌ One control file per framework (guaranteed duplication and contradictions within a year).
• ❌ Closing a finding without verifying the fix or recording the root cause.

8. Mandatory web verification

Before pinning any concrete fact, search for it — do not recall it. European regulation moves by quarters:

• NIS2 in Spain: whether the Ley de Coordinación y Gobernanza de la Ciberseguridad has been published in the BOE, its registration deadlines, the split of competent authorities and the final penalties (BOE + status of file INFR(2024)0270).
• DORA: RTS/ITS adopted and in force, and the updated list of CTPPs designated by the ESAs.
• ENS: whether RD 311/2022 is still in force unamended, and the Perfil de Cumplimiento Específico and the CCN-STIC guides applicable to the exact sector before sizing measures.
• CRA: Commission guidance and the status of the Single Reporting Platform before 11 Sep 2026.
• ISO: current edition and transition period of 27001/27002/27005/27701/42001, and whether there is a revision under way (ISO Online Browsing Platform / committee website).
• CIS Controls: current version (v8.1 as of Aug 2026; check whether v9 has been released) and its mappings.
• NIST: CSF 2.0, Quick Start Guides and CPRT for updated informative references; current OSCAL line and its actual support in the target tools.
• SOC 2: whether the AICPA has published new TSC or revision drafts.

If you cannot verify, say so explicitly instead of assuming. If the web contradicts this document, the web wins — flag the discrepancy.