VS-NfD (Verschlusssache — Nur für den Dienstgebrauch, “Classified — For Official Use Only”) is the lowest of Germany’s four classification levels (VS-NfD, VS-Vertraulich, Geheim, Streng Geheim). The legal and regulatory framework governing its handling consists of the Sicherheitsüberprüfungsgesetz (SÜG) as the legal basis, the Verschlusssachenanweisung (VSA) as the administrative directive for federal agencies (fundamentally revised in 2023), and the VS-NfD-Merkblatt (Annex 4 to the Geheimschutzhandbuch) for private-sector companies handling classified contracts. The framework is administered by the BSI for IT security aspects and the BMWK (Federal Ministry for Economic Affairs) for industrial security (Geheimschutz in der Wirtschaft). Compliance is absolutely mandatory — it is a legal obligation under the SÜG, and failure to comply results in loss of the ability to participate in classified government contracts. Key IT requirements include: using exclusively BSI-approved (zugelassen) IT security products listed in the VS-Produktkatalog (BSI-Schrift 7164) for encryption, VPN, and security-critical functions; implementing an information security concept based on BSI IT-Grundschutz (including risk analysis and Grundschutz-Check); applying the multi-layered security principle (prevention, detection, reaction); and personnel security clearances under the SÜG. Since 1 September 2025, a mandatory self-accreditation (Selbstakkreditierung) obligation entered into force: every three years, the VS-NfD-responsible person must formally confirm to their management (and on request to the BMWK or the contracting authority) that all technical and organizational measures are fully implemented. The BSI’s IT-Grundschutz module CON.11.1 specifically addresses VS-NfD requirements that go beyond standard IT-Grundschutz measures.
VEX (Vulnerability Exploitability eXchange) is a machine-readable assertion format that answers the question an SBOM alone cannot: given that a product contains a component affected by a known CVE, is that vulnerability actually exploitable in this specific product? An SBOM identifies components and versions; a CVE database maps those versions to known vulnerabilities; but the intersection of the two systematically overstates actual risk. A container image built on a minimal base may include a library with a known buffer overflow in a network-parsing function — but if that function is never called by anything in the image, or the affected code path requires a configuration flag that is hardcoded off, the CVE is present but not exploitable. Without VEX, every scanner that ingests the SBOM raises an alert; with VEX, the supplier asserts the non-exploitability with a machine-readable justification that automated tooling can consume to suppress the alert without human triage. VEX originated in the same NTIA multistakeholder process that produced the SBOM minimum elements framework, and was formalised by CISA in 2021–2022.
SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA (American Institute of Certified Public Accountants). It is not government legislation or a certification scheme but a voluntary attestation standard — however, it has become a de facto market requirement for any technology company, cloud service provider, or SaaS vendor serving enterprise customers, particularly in the US. A SOC 2 report is produced by an independent CPA firm that evaluates an organization’s controls against the AICPA’s Trust Services Criteria (TSC), organized in five categories: Security (mandatory for all SOC 2 reports, covering Common Criteria CC1–CC9), Availability, Processing Integrity, Confidentiality, and Privacy (each optional depending on the organization’s services and customer commitments). The Common Criteria (CC1–CC9) are derived from the COSO Internal Control Framework and cover control environment, risk assessment, monitoring, logical/physical access, system operations, change management, and risk mitigation. There are two report types: Type I (evaluates control design at a point in time) and Type II (evaluates both design and operating effectiveness over 6–12 months — the standard enterprise customers demand). SOC 2 reports are restricted-use documents shared with customers under NDA. While not legally mandatory, major enterprises, financial institutions, and regulated industries routinely require SOC 2 Type II reports from their vendors before signing contracts, making it an essential market-access requirement for technology service providers.
SIEM (Security Information and Event Management) is a platform that aggregates security telemetry from across an organisation’s infrastructure, normalises it into a common schema, applies correlation rules and behavioural analytics to detect threats, and retains the data for investigation and compliance reporting. The name combines two earlier disciplines: SIM (Security Information Management) — long-term log retention, compliance reporting, and forensic search — and SEM (Security Event Management) — real-time alert correlation and incident detection. Modern SIEMs do both simultaneously, serving as the primary visibility layer for a Security Operations Centre (SOC). Leading platforms include Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel, Elastic Security, Exabeam, and LogRhythm; all share the same fundamental architecture despite differing in query language (SPL for Splunk, KQL for Sentinel, EQL/KQL for Elastic, AQL for QRadar), correlation engine design (search-based vs dedicated CEP engine), and deployment model (on-premises, SaaS, or hybrid).
A Software Bill of Materials (SBOM) is a structured, machine-readable list of the components that make up a software artifact: open-source libraries, proprietary packages, operating system packages, programming language dependencies, and the transitive dependencies of all of the above. It is the software analogue of the ingredient list on packaged food — the thing that tells a consumer (or an automated system) precisely what is inside. The term and concept predate current security mandates but became a regulatory requirement in the US through Executive Order 14028 (May 2021), which directed NIST and NTIA to define minimum SBOM elements for software sold to the federal government. The NTIA’s resulting guidance specifies seven minimum data fields per component: supplier name, component name, version, component identifier (CPE or PURL), dependency relationships, SBOM author, and timestamp. The practical use cases SBOMs enable are vulnerability management (correlating component versions against CVE databases to identify affected software), licence compliance (detecting GPL or other licence obligations across the dependency graph), and incident response (determining within minutes which systems in a fleet contain a newly-disclosed vulnerable component, as organisations that had SBOMs could do during the Log4Shell response and those without could not).
The Payment Card Industry Data Security Standard (PCI-DSS) is a global security standard developed and maintained by the PCI Security Standards Council (PCI SSC), which was founded in 2006 by the five major payment card brands (Visa, Mastercard, American Express, Discover, JCB). The current version is PCI-DSS v4.0.1 (published June 2024, with mandatory compliance required from 31 March 2025 for all new requirements). PCI-DSS is not government legislation but a contractual obligation — compliance is enforced through the agreements between merchants/service providers and their acquiring banks. Failure to comply results in fines (up to $100,000/month from card brands), increased transaction fees, and ultimately loss of the ability to process card payments. PCI-DSS applies to any organization worldwide that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), regardless of size or transaction volume. The standard defines 12 requirements organized in 6 control objectives: build and maintain secure networks (firewalls, secure configurations), protect cardholder data (encryption, key management), maintain a vulnerability management program (patching, anti-malware), implement strong access controls (least privilege, MFA, physical access), regularly monitor and test networks (logging, penetration testing), and maintain an information security policy. Compliance is validated through either a Qualified Security Assessor (QSA) on-site assessment (Level 1 merchants) or a Self-Assessment Questionnaire (SAQ) for smaller entities.
Privileged Access Management (PAM) is the security discipline concerned with controlling, auditing, and minimising the use of privileged accounts: root access, domain administrator rights, cloud IAM roles with wide permissions, database superuser credentials, service account tokens, and any other identity that can cause systemic damage if misused. The threat PAM addresses is specific: an attacker who obtains a regular user credential can typically access that user’s data; an attacker who obtains a privileged credential can move laterally, disable security controls, exfiltrate everything, and deploy ransomware. PAM is therefore not a generalisation of identity and access management (IAM) but a specialisation of it — the same concepts of authentication and authorisation, applied with far higher friction to the accounts that most need it.
NIST Special Publication 800-53 is published by the National Institute of Standards and Technology (NIST), a US federal agency within the Department of Commerce. The current version is Revision 5 (September 2020, updated December 2020), which defines over 1,000 security and privacy controls organized in 20 control families (Access Control, Audit and Accountability, Configuration Management, Incident Response, System and Communications Protection, Supply Chain Risk Management, etc.). NIST 800-53 is mandatory for US federal agencies and their contractors under FISMA (Federal Information Security Modernization Act) and serves as the control baseline for FedRAMP (cloud), CMMC (defense contractors), and many state/local government programs. Beyond the US, it is widely adopted internationally as a comprehensive reference catalog — organizations in finance, healthcare, and critical infrastructure worldwide use NIST 800-53 as their control framework. The standard defines three baselines (Low, Moderate, High) corresponding to the potential impact of a security breach. NIST 800-53 is not a certification itself but the control catalog against which systems are assessed; formal authorization (ATO — Authority to Operate) is granted by an authorizing official after an assessor verifies control implementation using NIST SP 800-53A assessment procedures. The companion OSCAL (Open Security Controls Assessment Language) standard, also from NIST, provides machine-readable formats for expressing 800-53 controls and assessment results.
The NIS2 Directive (EU 2022/2555) is an EU directive — the successor to the original NIS1 of 2016 — that entered into force on 16 January 2023 with a transposition deadline of 17 October 2024, meaning each EU Member State was required to adopt it into national law by that date and enforce it from 18 October 2024 onward. NIS2 is issued by the European Parliament and Council; as a directive (not a regulation), its exact requirements vary by Member State, but the baseline obligations are binding. It applies to medium and large organizations (50+ employees or €10M+ annual turnover) operating in 18 critical sectors including energy, transport, health, banking, digital infrastructure, ICT service management, public administration, and manufacturing. Entities are classified as essential (proactive supervision, fines up to €10M or 2 % of global turnover) or important (reactive supervision, fines up to €7M or 1.4 % of turnover). Compliance is mandatory — management bodies are personally liable for overseeing cybersecurity risk management. Key obligations include implementing proportionate technical and organizational security measures, conducting supply chain risk assessments, reporting significant incidents to the national CSIRT within 24 hours (early warning), 72 hours (full notification), and one month (final report), and cooperating with national cybersecurity authorities. Member States were required to publish their lists of essential and important entities by 17 April 2025.
KRITIS (Kritische Infrastrukturen) is Germany’s national regulatory framework for the security and resilience of critical infrastructure. It is enforced by the BSI (Bundesamt für Sicherheit in der Informationstechnik — Federal Office for Information Security) and, for physical resilience, by the BBK (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe — Federal Office of Civil Protection). The framework is now governed by two primary laws: the NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), which rewrote the BSI-Gesetz and entered into force on 6 December 2025, and the KRITIS-Dachgesetz (KRITISDachG) for physical resilience, in force since 17 March 2026. Together they transpose the EU NIS2 Directive and CER Directive into German law. The scope expanded dramatically: from approximately 4,000 regulated entities under the previous IT-Sicherheitsgesetz 2.0 to around 30,000 entities now classified as either “besonders wichtige Einrichtungen” (particularly important, equivalent to NIS2 essential) or “wichtige Einrichtungen” (important). KRITIS applies to organizations in 18 sectors (energy, water, health, finance, transport, digital infrastructure, space, public administration, manufacturing, etc.) meeting defined size thresholds. Compliance is mandatory with no transitional period: entities must register with the BSI, implement risk management (§30 BSIG), report security incidents within 24 hours (§32), and management is personally liable (§38) for overseeing cybersecurity measures. Penalties reach up to €10M or 2 % of global turnover for particularly important entities.
The CISA Known Exploited Vulnerabilities (KEV) Catalog is a living database maintained by the US Cybersecurity and Infrastructure Security Agency that lists CVEs for which CISA has obtained reliable evidence of active exploitation in the wild. It was established under Binding Operational Directive 22-01 (BOD 22-01), issued in November 2021, which requires all US Federal Civilian Executive Branch (FCEB) agencies to remediate KEV-listed vulnerabilities within prescribed timeframes — typically 2 weeks for critical vulnerabilities and up to 6 months for older ones. A vulnerability must meet three criteria to be added: it must have a CVE ID, there must be reliable evidence of exploitation in the wild (not just a proof-of-concept or theoretical risk), and there must be clear remediation guidance available. CISA accepts nominations from the public and adds vulnerabilities continuously; the catalog is available in CSV and JSON formats at a stable URL, making it machine-consumable for integration into vulnerability management platforms and asset inventory tools.
ISO/IEC 27001 is the world’s most widely recognized standard for Information Security Management Systems (ISMS). It is published jointly by ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) — making it a truly international standard, not tied to any single country or jurisdiction. The current version is ISO/IEC 27001:2022, which replaced the 2013 edition and restructured its Annex A controls to align with the updated ISO/IEC 27002:2022 guidance (93 controls organized in 4 themes: Organizational, People, Physical, Technological). The standard specifies requirements (clauses 4–10) for establishing, implementing, maintaining, and continually improving an ISMS — covering context analysis, leadership commitment, risk assessment, treatment planning, operational controls, performance evaluation, and continuous improvement. Certification is voluntary but has become a global market expectation: ISO 27001 certification is required by countless procurement policies, regulatory frameworks (NIS2 references it, ENS aligns with it, E-ITS accepts it as equivalent, BSI IT-Grundschutz enables ISO 27001 certification), and customer contracts. Certification is issued by accredited certification bodies (accredited under ISO/IEC 17021) following a two-stage audit process, valid for 3 years with annual surveillance audits. Over 70,000 organizations worldwide hold ISO 27001 certification. Unlike prescriptive frameworks (DISA STIG, CIS Benchmarks), ISO 27001 is risk-based and outcome-oriented — it specifies what must be achieved but not how, allowing organizations to tailor implementations to their context.
The Health Insurance Portability and Accountability Act (HIPAA) is a United States federal law enacted in 1996 and enforced by the Department of Health and Human Services (HHS) Office for Civil Rights (OCR). HIPAA is not a voluntary standard or certification — it is mandatory US law with civil and criminal penalties for non-compliance (fines up to $1.5M per violation category per year, and criminal penalties including imprisonment). HIPAA applies to covered entities (health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically) and their business associates (any entity that creates, receives, maintains, or transmits Protected Health Information — PHI — on behalf of a covered entity). The law’s security requirements are defined primarily in two rules: the Privacy Rule (what PHI can be used and disclosed) and the Security Rule (administrative, physical, and technical safeguards required to protect electronic PHI — ePHI). Key technical requirements include access controls, audit controls, integrity controls, transmission security (encryption), and contingency planning. Unlike prescriptive standards (like CIS or DISA STIG), HIPAA’s Security Rule is flexible and scalable — it defines required outcomes but allows organizations to determine the specific technologies used. The Breach Notification Rule requires reporting unauthorized disclosures to HHS and affected individuals within 60 days. HIPAA has no “certification” — compliance is demonstrated through documented risk assessments, policies, and technical controls.
The GSMA Network Equipment Security Assurance Scheme (NESAS) is a voluntary, global security assurance framework jointly led by the GSMA and 3GPP. It was established to provide a universal, industry-driven security evaluation for mobile network equipment — primarily targeting 4G/LTE and 5G infrastructure — that avoids the fragmentation of country-specific security requirements. NESAS operates through two complementary components: first, an audit of the vendor’s development and product lifecycle processes (covering secure design, implementation, testing, and vulnerability handling), conducted by GSMA-appointed auditing organizations; second, a product evaluation against 3GPP-defined Security Assurance Specifications (SCAS), performed by ISO/IEC 17025 accredited security test laboratories. The GSMA manages scheme governance (accreditation, dispute resolution, publication of results), while 3GPP’s SA3 working group defines the technical security requirements and test cases in SCAS documents. The scheme is currently at NESAS v3.0 (specifications published early 2025), which introduces revised security requirements and expands coverage to include virtualized network functions. NESAS is voluntary — no government mandates it — but it is increasingly referenced by national 5G security reviews and procurement requirements (including the EU 5G Toolbox), and major operators use NESAS assessment results as a procurement criterion. Evaluated vendors and their results are publicly listed on the GSMA website.
FIPS 140 (Federal Information Processing Standard, Publication 140) is the US and Canadian government standard that defines security requirements for cryptographic modules — the hardware, software, or firmware components that perform cryptographic operations (encryption, decryption, hashing, signing, key management). It is published by NIST (National Institute of Standards and Technology) and jointly administered with CCCS (Canadian Centre for Cyber Security) through the Cryptographic Module Validation Program (CMVP). The standard has two active versions: FIPS 140-2 (published 2001, no longer accepting new submissions since April 2022) and FIPS 140-3 (effective September 2020, the current standard for all new validations). FIPS 140-2 certificates remain valid until 21 September 2026, after which they move to the Historical list — meaning only FIPS 140-3 validated modules will be accepted for new federal procurements. FIPS 140 defines four security levels (Level 1 through Level 4), with Level 1 being the baseline for software modules and Level 4 requiring physical tamper-active hardware. Compliance is mandatory for all US federal agencies and their contractors under FISMA, for Canadian federal systems, and is widely adopted by regulated industries (finance, healthcare, critical infrastructure) globally. Non-validated cryptography is treated as providing no protection — effectively plaintext — regardless of the algorithm strength. Validation is a formal, lab-based process: vendors submit modules to accredited Cryptographic and Security Testing (CST) laboratories, which test against the standard and submit results to CMVP for certificate issuance.
The Federal Risk and Authorization Management Program (FedRAMP) is a US government-wide program, codified into law by the FedRAMP Authorization Act of 2022, that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. FedRAMP is administered by the General Services Administration (GSA) and is mandatory — any cloud service (SaaS, PaaS, IaaS) that stores, processes, or transmits federal data or metadata must achieve FedRAMP authorization before it can be used by US government agencies or their contractors. The program defines three impact levels: Low (limited adverse effect), Moderate (serious adverse effect), and High (severe or catastrophic effect — applies to law enforcement, emergency, financial, and health systems). Each level maps to NIST SP 800-53 Rev 5 control baselines: FedRAMP High requires implementation of approximately 421 controls. Authorization is achieved through either an Agency ATO (a specific agency sponsors the assessment) or the newer FedRAMP 20-X experimental accelerated path. Once authorized, cloud service providers (CSPs) must maintain continuous monitoring — monthly vulnerability scans, annual penetration testing, and Plan of Action & Milestones (POA&M) reporting — or risk revocation. Authorized services are listed on the FedRAMP Marketplace.
The European Common Criteria-based cybersecurity certification scheme (EUCC) is the first certification scheme formally adopted under the EU Cybersecurity Act (Regulation 2019/881). The European Commission published the implementing regulation on 31 January 2024, and an amendment (Regulation 2024/3144) followed in December 2024 to clarify applicable ISO/IEC 15408 standard versions and transition rules. EUCC is managed by ENISA and builds on the existing SOG-IS Mutual Recognition Agreement that was already used by 17 EU Member States, effectively replacing those national Common Criteria schemes with a single EU-wide framework. It applies to ICT products — hardware, software, and embedded components — and evaluates their cybersecurity properties through accredited Conformity Assessment Bodies (CABs). The scheme offers two assurance levels: “substantial” (based on AVA_VAN levels 1–2) and “high” (AVA_VAN levels 3–5). Certification is voluntary — there is no legal obligation to certify ICT products under EUCC — but it provides market-recognized evidence of security properties and is expected to be referenced by procurement requirements and sector-specific legislation (e.g. medical devices, smart metering). EUCC certificates are recognized uniformly across the entire EU, eliminating the need for country-by-country certification.
The EU5G cybersecurity certification scheme is a certification framework being developed under the EU Cybersecurity Act (Regulation 2019/881), intended to provide harmonized security assurance for 5G network products and components across the European Union. ENISA established an Ad Hoc Working Group (AHWG) on EU5G in Q4 2021 following a European Commission request. As of mid-2026, the scheme has not been formally adopted and no complete public draft is available — making it the least mature of the three schemes requested under the CSA (after EUCC, adopted in January 2024, and EUCS, still stalled). Current work has focused on specific components: in June 2024, ENISA launched a public consultation on technical specifications for eUICC (embedded Universal Integrated Circuit Card) certification, which will be handled under the existing EUCC framework rather than a new standalone scheme. A broader EU NESAS scheme for 5G network products is under development, leveraging the existing GSMA NESAS/3GPP SCAS methodology. The scheme is expected to be voluntary once adopted, with assurance levels aligned to the CSA’s basic/substantial/high structure. Its practical significance will be shaped by the revised Cybersecurity Act (CSA2), proposed in January 2026, which strengthens ENISA’s mandate and may provide additional impetus for adoption.
The EU Cybersecurity Act (CSA) — Regulation (EU) 2019/881 — was adopted by the European Council in April 2019 and fully entered into force on 28 June 2021. It is a European regulation (directly applicable in all Member States without transposition) that serves two primary functions: it strengthened and made permanent the mandate of ENISA (the EU Agency for Cybersecurity), and it established a voluntary EU-wide cybersecurity certification framework for ICT products, services, and processes. The CSA is not itself a certification scheme but rather the legal foundation upon which specific schemes are built — currently EUCC (adopted January 2024), EUCS (cloud, under development), EU5G (5G networks, under development), EUDI Wallets, and EUMSS (managed security services). Each scheme defines assurance levels (basic, substantial, high), evaluation methodologies, and mutual recognition rules so that a certificate issued in one Member State is valid across the entire EU. The CSA applies to any entity — manufacturer, service provider, or operator — that voluntarily seeks EU cybersecurity certification for its offerings, though sector-specific regulations (NIS2, CRA, DORA) may make certification effectively mandatory for certain use cases. A recast of the CSA (CSA2) was proposed by the European Commission on 20 January 2026, aiming to strengthen certification mandates, reinstate sovereignty requirements in cloud certification, and reinforce ENISA’s supervisory role.
The Cyber Resilience Act (CRA) is a European Union regulation — not a voluntary standard — that entered into force on 10 December 2024 and will be fully applicable on 11 December 2027. It is issued by the European Commission and co-legislated by the European Parliament and Council; it is not a certification scheme but a horizontal product-safety law, comparable in structure to the CE-marking directives for physical goods. The CRA applies to all manufacturers, importers, and distributors of “products with digital elements” — any software or hardware product containing a data connection — that is made available on the EU single market, regardless of where the manufacturer is headquartered. Compliance is mandatory: non-compliant products cannot legally be placed on the EU market after the deadline, and penalties can reach €15 million or 2.5 % of global annual turnover. Key intermediate deadlines include 11 September 2026 (manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours) and 11 June 2026 (conformity assessment body framework becomes operational). Products already on the market before 11 December 2027 are exempt from the full requirements unless they undergo a “substantial modification,” but they are subject to the vulnerability reporting obligation from September 2026 onward.
