Modern Cybersecurity Standards: Zero Trust, NIST, ISO, OWASP, Cloud, Privacy and AI

Cybersecurity has no single universal standard. A business may use one framework to govern risk, another to specify application controls, several protocols to authenticate users, a maturity model to plan improvements, and laws to define mandatory obligations.

That is why terms such as Zero Trust, NIST, ISO 27001, SOC 2, OWASP, PCI DSS, CIS Controls, SLSA, and GDPR often appear together even though they solve different problems.

This guide is a practical map of the modern security landscape as of August 2026. It covers more than 100 widely used standards, frameworks, protocols, regulations, catalogs, and engineering models. It is intentionally broad, but it is not a promise that every document applies to every organization.

A standard is not a shopping list. Select requirements from your risks, systems, customers, contracts, and jurisdictions. Compliance can support security, but it does not replace threat modeling, sound engineering, monitoring, or practiced recovery.

First: know what kind of document you are reading

A standard defines requirements or specifications against which an implementation or management system may be assessed. Examples: ISO/IEC 27001, PCI DSS, TLS 1.3.
A framework organizes outcomes and activities without prescribing one implementation. Examples: NIST CSF 2.0 and NIST AI RMF.
A control catalog supplies detailed safeguards from which an organization selects. Examples: NIST SP 800-53 and CIS Controls.
A maturity model describes stages of capability. Examples: CISA Zero Trust Maturity Model and OWASP SAMM.
A protocol defines interoperable technical behavior. Examples: OAuth, OpenID Connect, SAML, WebAuthn, DNSSEC, and TLS.
A threat or weakness taxonomy gives teams a shared language. Examples: MITRE ATT&CK, CWE, CAPEC, and OWASP Top 10.
A regulation or law creates legal obligations. Examples: GDPR, NIS2, DORA, the EU Cyber Resilience Act, and Vietnam’s cybersecurity and personal-data laws.
A certification or attestation is evidence about a defined scope at a point or period in time. Examples: ISO 27001 certification, SOC 2 reporting, and CSA STAR assurance.

The shortest useful adoption path

If the full list feels overwhelming, start here:

Use NIST CSF 2.0 or CIS Controls v8.1 to organize the program.
Use NIST SP 800-207 and the CISA Zero Trust Maturity Model to redesign access around identity, device posture, resources, and continuous evaluation.
Use OWASP ASVS 5.0 for web application requirements, OWASP API Security Top 10 for APIs, and NIST SSDF for the development lifecycle.
Require phishing-resistant MFA or passkeys using FIDO2/WebAuthn, then modernize OAuth deployments according to RFC 9700.
Maintain an asset inventory, data inventory, dependency inventory, and tested recovery plan.
Produce an SBOM using SPDX or CycloneDX, protect builds with SLSA, and sign releases and provenance.
Prioritize vulnerabilities with business context, known exploitation, CVSS 4.0, and EPSS, not a base score alone.
Map applicable legal, contractual, and industry requirements, then record evidence once and reuse it across frameworks.

1. Zero Trust architecture and access

Zero Trust is not “trust nobody,” a VPN replacement, or a vendor product. It is the removal of implicit trust based only on network location or asset ownership. Access decisions should consider identity, device, resource, policy, risk, and current context.

NIST SP 800-207: Zero Trust Architecture. The foundational neutral definition of Zero Trust. It shifts protection from network segments toward users, devices, applications, services, and resources. Authentication and authorization occur before a session and can be continuously reevaluated. See the official NIST publication.
NIST SP 800-207A: Cloud-native Zero Trust access control. Extends Zero Trust to applications and services across hybrid and multi-cloud environments. It emphasizes application and workload identities, API gateways, sidecar proxies, service meshes, and identity-tier policies.
NIST SP 1800-35: Implementing a Zero Trust Architecture. Finalized in 2025, this practice guide documents 19 example implementations built with 24 collaborators. Use it to move from diagrams to deployable patterns and integration lessons.
CISA Zero Trust Maturity Model 2.0. Organizes a Zero Trust program into five pillars: identity, devices, networks, applications and workloads, and data. Visibility and analytics, automation and orchestration, and governance extend across all five pillars. Its stages are Traditional, Initial, Advanced, and Optimal.
Software-Defined Perimeter (SDP). A pattern that hides services until identity and policy checks succeed. It can support Zero Trust network access, but SDP alone is not a complete Zero Trust architecture.
Zero Trust Network Access (ZTNA). Product and architecture category for per-application access based on identity and context. Prefer resource-level policy, device posture, short-lived sessions, and strong telemetry over simply replacing one remote-access tunnel with another.
SASE and Security Service Edge (SSE). SASE combines wide-area networking with cloud-delivered security; SSE covers the security portion, commonly including secure web gateways, cloud access security brokers, ZTNA, and data controls. These are architecture categories, not certifications.
Microsegmentation. Limits east-west movement between workloads and resources. It should use service or workload identity where possible rather than brittle IP-only rules.
Policy decision and enforcement points. A mature Zero Trust design separates policy decisions from enforcement, logs the context used, denies safely when dependencies fail, and supports rapid revocation.
Continuous Adaptive Risk and Trust Assessment (CARTA). A Gartner-originated model rather than an open standard, but useful language for continuous, risk-aware decisions. Treat it as strategy guidance, not a conformity target.

2. Governance, risk, and enterprise control frameworks

NIST Cybersecurity Framework 2.0 (CSF). A universal outcome framework organized into Govern, Identify, Protect, Detect, Respond, and Recover. Version 2.0 made governance explicit and is designed for organizations of any size or sector. Build a Current Profile, a Target Profile, and a prioritized action plan. Start at the NIST CSF 2.0 resource center.
NIST SP 800-53 Rev. 5. A large catalog of security and privacy controls for systems and organizations. It is excellent for detailed requirements, overlays, and evidence mapping; it is too large to adopt blindly.
NIST Risk Management Framework: SP 800-37 Rev. 2. A lifecycle for preparing, categorizing systems, selecting and implementing controls, assessing them, authorizing operation, and monitoring continuously.
NIST SP 800-30: Guide for Conducting Risk Assessments. A structured way to identify threat sources, events, vulnerabilities, likelihood, impact, and risk. Use it to stop risk registers from becoming unranked lists of fears.
NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management. Applies risk management to suppliers, products, services, dependencies, and the acquisition lifecycle.
CIS Critical Security Controls v8.1. Eighteen prioritized controls and safeguards. Implementation Groups IG1, IG2, and IG3 let smaller organizations start with essential cyber hygiene and expand with risk. Version 8.1 aligns with the Govern function in CSF 2.0. See the official CIS Controls page.
CIS Benchmarks. Prescriptive secure-configuration baselines for operating systems, cloud services, databases, containers, network devices, and applications. Tailor and test them; a hardened system that breaks the business will be bypassed.
ISO/IEC 27001:2022. The requirements standard for an information security management system (ISMS). It is risk-based and certifiable within a defined scope. The certificate is not proof that every system is invulnerable. See ISO’s overview.
ISO/IEC 27002:2022. Implementation guidance for information security controls. It complements ISO 27001 but is not itself the ISMS certification standard.
ISO/IEC 27005. Guidance for information security risk management, useful when developing the assessment and treatment process behind an ISMS.
ISO/IEC 27014. Governance of information security: how governing bodies evaluate, direct, monitor, and communicate security.
COBIT 2019. An ISACA framework for governance and management of enterprise information and technology. It is broader than cybersecurity and useful for accountability, objectives, capability assessment, and alignment with business goals.
SOC 2 Trust Services Criteria. An AICPA attestation framework covering Security and optional Availability, Processing Integrity, Confidentiality, and Privacy criteria. A Type I report examines design at a date; Type II examines operation over a period. Always read the scope, exceptions, complementary controls, and subservice organizations.
CSA Cloud Controls Matrix (CCM) v4 and CAIQ. Cloud-specific control domains and assessment questions from the Cloud Security Alliance. Useful for cloud providers and customers mapping shared-responsibility controls.
CSA STAR. A cloud assurance registry and program that builds on CCM through self-assessment, third-party certification or attestation, and continuous assurance levels.
FAIR. Factor Analysis of Information Risk provides a quantitative model for estimating the frequency and magnitude of loss. Use ranges and calibrated assumptions; do not disguise uncertain inputs as precise truth.

3. Identity, authentication, authorization, and secrets

NIST SP 800-63-4 Digital Identity Guidelines. Finalized in 2025, Revision 4 covers identity proofing, authentication, authenticator management, federation, fraud and assurance levels. It supersedes Revision 3 and explicitly addresses synced passkeys, forged media, and continuous metrics. See the NIST Revision 4 portal.
FIDO2: WebAuthn and CTAP. The modern foundation for phishing-resistant authentication. WebAuthn defines the web API; CTAP connects clients to authenticators. Passkeys are FIDO credentials, not a separate security standard. Keep account recovery at least as strong as sign-in.
WebAuthn Level 3. W3C’s current Candidate Recommendation work expands public-key credential capabilities. Check browser support and the specification’s status before relying on Level 3-only features.
OAuth 2.0 and RFC 9700. OAuth delegates authorization; it is not an authentication protocol. RFC 9700 is the current OAuth 2.0 Security Best Current Practice: use authorization code with PKCE, exact redirect matching, sender-constrained tokens where justified, and avoid deprecated flows. OAuth 2.1 remains under development, so do not label a draft as a final standard. See RFC 9700.
OpenID Connect (OIDC). An identity layer on OAuth 2.0 that standardizes authentication and ID tokens. Validate issuer, audience, signature, nonce, time claims, and the exact flow used.
OpenID FAPI 2.0. A high-security OAuth profile for financial-grade APIs and other high-value data sharing. Its Security Profile became final in 2025; Message Signing is also final. Prefer certified implementations for regulated ecosystems.
SAML 2.0. A mature XML-based federation protocol common in enterprise single sign-on. Protect signature validation, audience and recipient checks, replay handling, metadata trust, and XML parsing.
SCIM 2.0: RFC 7643 and RFC 7644. Standardizes identity provisioning and lifecycle operations. Secure deprovisioning is as important as onboarding; stale accounts silently defeat least privilege.
X.509 PKI and RFC 5280. The certificate and revocation profile behind TLS, mutual TLS, device identity, and many enterprise trust systems. Key lifecycle, issuance policy, rotation, revocation, and trust-store governance matter as much as certificate syntax.
SPIFFE and SPIRE. Open specifications and an implementation for issuing verifiable workload identities, commonly used in service meshes and cloud-native Zero Trust systems.
Role-Based Access Control (RBAC). Assigns permissions through roles. It is easy to understand but can create role explosion and excessive standing privilege.
Attribute-Based and Policy-Based Access Control (ABAC/PBAC). Decisions use attributes and context such as user, device, resource, action, risk, and time. These models fit dynamic Zero Trust policies but require high-quality attributes and explainable policy evaluation.
Privileged Access Management (PAM) and Just-in-Time access. Vault, rotate, approve, record, and time-limit privileged sessions. Eliminate permanent administrator access where practical and maintain emergency access with tested controls.
Secrets-management patterns. Use dedicated secret stores, workload identity, short-lived credentials, automated rotation, and secret scanning. Never treat environment variables, CI logs, source repositories, or client-side code as secure vaults.

4. Application, API, mobile, and software development security

OWASP Top 10:2025. The current awareness list for critical web application risks: Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions. It is a starting point, not a complete test standard. See the official 2025 list.
OWASP ASVS 5.0. A verifiable set of application security requirements and assessment levels. Use ASVS for requirements, architecture reviews, secure coding, tests, procurement, and acceptance criteria. OWASP released version 5.0.0 in 2025.
OWASP API Security Top 10:2023. Focuses on API-specific risks such as object- and function-level authorization, unrestricted resource consumption, sensitive business flows, server-side request forgery, inventory, and unsafe API consumption.
OWASP SAMM. A maturity model for Governance, Design, Implementation, Verification, and Operations. Use it to improve how software security is performed, rather than merely counting vulnerabilities.
OWASP MASVS and MASTG. Security requirements and testing guidance for mobile applications, covering storage, cryptography, authentication, network communication, platform interaction, code, resilience, and privacy.
OWASP Software Component Verification Standard (SCVS). A developing model for managing and verifying third-party component risk. Confirm its maturity and version before making it a contractual compliance target.
NIST SP 800-218: Secure Software Development Framework (SSDF) 1.1. A high-level secure-development framework organized around preparing the organization, protecting software, producing well-secured releases, and responding to vulnerabilities. See the official NIST SSDF.
Secure by Design and Secure by Default. CISA principles that place safety outcomes and ownership on technology manufacturers: eliminate default passwords, reduce entire vulnerability classes, make important security features available without extra cost, and publish measurable commitments.
Threat modeling: STRIDE. Classifies Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Use it early with data-flow diagrams and revisit it when trust boundaries change.
Threat modeling: attack trees, misuse cases, PASTA, and LINDDUN. Attack trees decompose attacker goals; misuse cases explore abuse; PASTA is risk-centric; LINDDUN focuses on privacy threats. Choose a method that produces decisions, not ceremonial diagrams.
Common Weakness Enumeration (CWE). A catalog of weakness types such as improper authorization or unsafe memory handling. Use CWE to classify root causes; use CVE to identify specific disclosed vulnerabilities.
Common Attack Pattern Enumeration and Classification (CAPEC). A catalog of attack patterns linked to weaknesses and mitigations. It is useful for threat modeling, testing ideas, and training.
Secure coding standards: SEI CERT and language guidance. Language-specific rules help with memory safety, integer handling, concurrency, error handling, and undefined behavior. Prefer memory-safe languages for new security-sensitive components when feasible.
Security testing families. SAST inspects source, DAST tests running systems, IAST observes execution, SCA inventories dependencies, fuzzing explores unexpected inputs, and penetration testing exercises attack paths. No single tool covers business logic or the entire OWASP Top 10.

5. Cloud, containers, Kubernetes, and infrastructure as code

Cloud shared responsibility. Not a single standard, but the essential operating model: the provider secures defined parts of the cloud while the customer remains responsible for data, identities, configurations, workloads, and other service-specific controls.
ISO/IEC 27017. Cloud security control guidance for cloud service providers and customers, extending the ISO 27002 control model.
ISO/IEC 27018. Protection of personally identifiable information in public-cloud processing when the cloud provider acts as a PII processor.
CSA CCM and Consensus Assessments Initiative Questionnaire. Use these to evaluate cloud controls, document provider responsibilities, and compare evidence without inventing a questionnaire from scratch.
CIS Foundations Benchmarks for cloud platforms. Baselines for accounts, identity, logging, networking, storage, databases, and platform services. Apply through policy as code and continuously detect drift.
NIST SP 800-190: Application Container Security Guide. Covers image, registry, orchestrator, container, and host risks. Although older, its risk model remains a useful baseline when combined with current platform guidance.
NSA/CISA Kubernetes Hardening Guidance. Practical recommendations for pod security, network separation, authentication and authorization, audit logging, supply-chain controls, and keeping Kubernetes components current.
Kubernetes Pod Security Standards. Defines Privileged, Baseline, and Restricted policy levels. Enforce an appropriate level with admission controls and narrowly document exceptions.
Infrastructure as Code security. Scan templates, modules, policies, and container definitions before deployment; require review and provenance; protect state files; and monitor deployed configuration for drift.
Policy as Code: OPA/Rego and related engines. Express and test authorization or configuration policy as versioned code. Policy engines do not fix unclear ownership or bad policy logic, so include unit tests, change review, and decision logs.
Cloud-native workload identity. Prefer short-lived, automatically issued service identities over embedded cloud keys. Bind privileges to workloads and environments, then constrain token audience and lifetime.

6. Software supply chain, SBOM, provenance, and vulnerability disclosure

SLSA 1.2: Supply-chain Levels for Software Artifacts. The current approved specification adds source and build tracks, levels, provenance, and verification concepts that improve confidence an artifact maps to protected source and an acceptable build process. See SLSA 1.2.
in-toto attestations. A framework for cryptographically verifiable statements about steps in a software supply chain. It underpins common provenance and attestation patterns.
The Update Framework (TUF). Protects software update systems against key compromise, rollback, freeze, mix-and-match, and repository attacks through separated roles and threshold trust.
SPDX 3.0. The current version of the international open standard for communicating software and other bill-of-materials information; SPDX is also ISO/IEC 5962:2021. See the official specifications page.
CycloneDX 1.7. The current OWASP/Ecma bill-of-materials standard supports components, services, dependencies, vulnerabilities, formulation, cryptographic assets, machine-learning models, annotations, and declarations. See the CycloneDX specification overview.
SBOM: Software Bill of Materials. An inventory, not a vulnerability report and not proof of safety. Generate it at build time, sign it, distribute it with access controls appropriate to the context, and connect it to asset and vulnerability management.
VEX: Vulnerability Exploitability eXchange. Communicates whether a known vulnerability affects a product in its actual context. It helps reduce false-positive work but requires a defensible status, justification, product identity, and update process.
Package URL (purl) and CPE. Identifier schemes used to connect components and products to vulnerability information. Neither perfectly identifies every artifact, so preserve hashes, versions, suppliers, and dependency relationships too.
Sigstore. An open ecosystem for signing and verifying software artifacts, identities, and transparency-log entries. It reduces key-management friction but still needs identity policy and verification at deployment.
OpenSSF Scorecard and Best Practices. Automated signals and project practices for open-source security. Use them as risk inputs, not as a binary declaration that a package is safe.
Coordinated Vulnerability Disclosure and ISO/IEC 29147. Defines how organizations receive, assess, coordinate, remediate, and disclose vulnerability reports.
ISO/IEC 30111. Defines internal vulnerability-handling processes. Pair it with a public security contact, a disclosure policy, service-level targets, safe-harbor language where appropriate, and security.txt under RFC 9116.

7. Network, web, email, and cryptographic standards

TLS 1.3: RFC 8446. The modern transport security protocol for data in transit. Disable obsolete SSL/TLS versions, automate certificate renewal, use current cipher configuration, and understand where TLS terminates. See RFC 8446.
HTTP Strict Transport Security: HSTS. Tells browsers to use HTTPS for a defined period. Roll out carefully before including subdomains or requesting preload because mistakes can cause long outages.
Content Security Policy (CSP). Restricts permitted content sources and helps reduce script injection impact. Prefer nonces or hashes and a strict policy; deploy in report-only mode first, remove unnecessary third-party scripts, then enforce.
Modern browser isolation headers. Use frame-ancestors in CSP against framing, X-Content-Type-Options: nosniff, a deliberate Referrer-Policy, Permissions-Policy, and COOP/COEP/CORP where cross-origin isolation is needed.
Secure cookies. Set Secure, HttpOnly, and an appropriate SameSite value; minimize scope with Path and Domain; rotate sessions after authentication; and use __Host- cookies when the constraints fit.
DNSSEC. Adds origin authentication and integrity to DNS data. It does not encrypt queries; use secure resolvers and encrypted DNS transports where those match the threat model.
CAA and certificate transparency. CAA limits which certificate authorities may issue for a domain. Certificate Transparency logs help domain owners detect unexpected issuance.
SPF, DKIM, and DMARC. SPF authorizes sending infrastructure, DKIM signs messages, and DMARC aligns visible sender domains and defines handling/reporting policy. Move gradually toward enforcement and monitor every legitimate sender.
DANE, MTA-STS, and TLS reporting. Additional mechanisms for protecting mail transport and reporting TLS failures. Applicability depends on DNSSEC, provider support, and operational maturity.
HTTP Message Signatures: RFC 9421. Signs selected HTTP message components at the application layer. It can protect integrity and authenticity across intermediaries but does not replace TLS and requires replay defenses and key management.
Cryptographic module validation: FIPS 140-3. A security standard for cryptographic modules used in U.S. federal and many regulated contexts. “Uses AES” is not the same as using a validated module in an approved mode.
Key management: NIST SP 800-57. Guidance for cryptographic key lifecycle, strength, protection, rotation, backup, recovery, revocation, and destruction.
Post-quantum cryptography: FIPS 203, 204, and 205. NIST finalized ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures in 2024. Inventory cryptographic dependencies, identify long-lived data vulnerable to “harvest now, decrypt later,” and plan crypto-agile migration. Do not invent a home-grown hybrid scheme. See the NIST PQC project.

8. Data security and privacy

Privacy by Design and by Default. Minimize collection, constrain purpose, set protective defaults, separate duties, and build retention and deletion into the system rather than adding a privacy notice after deployment.
NIST Privacy Framework 1.0. A voluntary risk framework for identifying and managing privacy risk. NIST is developing an update, so distinguish published version 1.0 from drafts.
ISO/IEC 27701. Extends an ISO 27001/27002 management system with privacy information management controls for PII controllers and processors. Verify the applicable edition and certification scheme with your auditor.
ISO/IEC 27040. Storage security guidance across design, implementation, operation, and end-of-life.
Data classification and lifecycle controls. Inventory data; classify sensitivity and criticality; define approved collection, access, sharing, retention, archival, and deletion; and propagate labels into logs, backups, analytics, and AI systems.
Tokenization, masking, and privacy-enhancing technologies. Use tokenization to reduce exposure of sensitive values, masking to limit presentation, and techniques such as differential privacy or confidential computing where the use case and threat model justify them.
GDPR. The EU’s data protection regulation applies based on processing context and territorial scope, not simply company location. It covers lawful bases, transparency, data-subject rights, processor relationships, security, breach notification, transfers, and accountability.
California CCPA as amended by CPRA. Establishes consumer rights and obligations for covered businesses, including access, deletion, correction, opt-out, sensitive-data limitations, and vendor contract duties.
Vietnam Law on Personal Data Protection 91/2025/QH15. In force from January 1, 2026, with Decree 356/2025/ND-CP replacing Decree 13/2023. Vietnamese organizations should review processing-impact assessments, cross-border transfers, sensitive data, responsible personnel, consent and other lawful processing grounds, incident duties, contracts, and data-subject rights. See the Vietnam Government’s announcement.

9. Vulnerabilities, adversary behavior, detection, and incident response

CVE. A common identifier for a publicly disclosed vulnerability. A CVE record is not a risk decision, a patch, or proof that your specific deployment is exploitable.
CVSS 4.0. FIRST’s current standard for communicating technical vulnerability characteristics and severity. Use Base, Threat, Environmental, and Supplemental metrics as appropriate. Do not sort the entire patch queue by Base score alone. See FIRST CVSS 4.0.
EPSS. A data-driven estimate of the probability that a published CVE will be exploited in the wild in the next 30 days. Combine it with asset exposure, business impact, compensating controls, and known-exploitation evidence.
CISA Known Exploited Vulnerabilities (KEV) Catalog. A high-value prioritization input listing vulnerabilities with evidence of active exploitation. Organizations outside U.S. federal scope can still use it to accelerate remediation.
MITRE ATT&CK. A knowledge base of adversary tactics and techniques for Enterprise, Mobile, and ICS. Use it to model threats, design detections, run exercises, and identify coverage gaps. ATT&CK v19.1 was current in August 2026; treat versioned mappings as living content.
MITRE D3FEND. A knowledge graph of defensive techniques that can help connect adversary behavior to candidate countermeasures.
Cyber Kill Chain. A high-level intrusion lifecycle useful for communication, though ATT&CK usually provides more detailed behavior. Do not assume every modern attack is a linear chain.
Detection engineering: Sigma, YARA, and STIX/TAXII. Sigma expresses portable log detections, YARA matches file or memory patterns, and STIX/TAXII structures and transports threat intelligence. Quality depends on telemetry, tuning, context, and lifecycle ownership.
NIST SP 800-61 Rev. 3. The current NIST incident response guidance, finalized in 2025 and aligned with all six CSF 2.0 functions. It supersedes Revision 2 and treats incident response as organization-wide risk management. See NIST’s Revision 3 announcement.
NIST SP 800-92: Log Management. Guidance for log infrastructure and processes. Modern implementations should add cloud, identity, application, API, SaaS, endpoint, and build-system telemetry.
Security Operations maturity. SIEM centralizes and correlates events; SOAR automates workflows; EDR/XDR provides endpoint and cross-domain detection; UEBA models behavior. Tools only help when telemetry, detection ownership, triage, containment authority, and testing are defined.

10. Resilience, continuity, recovery, and third-party risk

ISO 22301. The certifiable management-system standard for business continuity. It connects business impact analysis, continuity strategies, exercises, and continual improvement.
NIST SP 800-34. Contingency-planning guidance for information systems, including business impact analysis, recovery strategies, plan development, testing, training, and maintenance.
The 3-2-1 backup pattern, with immutability and restore testing. Keep multiple copies on different media with one off-site; for ransomware resilience add isolated or immutable copies, separate credentials, monitored jobs, recovery objectives, and routine restore exercises.
Operational resilience and chaos engineering. Test how systems behave when dependencies, regions, credentials, queues, or control planes fail. Security includes availability and safe recovery, not only confidentiality.
Third-party risk management. Tier suppliers by criticality and data access; perform due diligence; define security and incident clauses; monitor material changes; plan exit and data return or deletion; and assess concentration and fourth-party risk.

11. Industry requirements and cyber regulations

PCI DSS 4.0.1. The current payment-card data security standard for entities that store, process, transmit, or can affect cardholder data environments. Version 4.0.1 is a limited revision, not a new weakening of the requirements. Scope reduction and trusted payment providers can greatly reduce risk. See the PCI SSC document library.
HIPAA Security Rule. U.S. safeguards for electronic protected health information, alongside Privacy and Breach Notification requirements. Organizations must track current rulemaking and sector guidance rather than relying on a decade-old checklist.
HITRUST CSF. A certifiable assurance framework that harmonizes healthcare and other requirements. It is not a government regulation and does not replace determining which laws apply.
FedRAMP. A standardized U.S. federal approach to security assessment, authorization, and continuous monitoring for cloud services. Requirements depend on authorization path and impact level.
CMMC 2.0 and NIST SP 800-171 Rev. 3. Relevant to U.S. Defense Industrial Base contractors handling Federal Contract Information or Controlled Unclassified Information. Contract clauses and official assessment rules determine obligations.
NIS2. The EU directive raises cybersecurity risk-management, governance, supply-chain, incident-reporting, and supervision expectations for covered essential and important entities. Applicability depends on sector, size, establishment, and national transposition.
DORA. The EU Digital Operational Resilience Act applies sector-specific requirements to covered financial entities and ICT third-party risk, incident management and reporting, resilience testing, and oversight.
EU Cyber Resilience Act (CRA). Creates lifecycle cybersecurity obligations for products with digital elements. Most provisions apply from December 11, 2027, while vulnerability and severe-incident reporting applies from September 11, 2026. Product teams need vulnerability handling, secure updates, technical documentation, conformity work, and support-period planning now. See the official EUR-Lex summary.
EU AI Act. A risk-based regulation for AI systems with duties depending on the role and risk category. Security teams should connect AI governance, data governance, model evaluation, logging, human oversight, incident processes, and supply-chain documentation.
Vietnam Cybersecurity Law 116/2025/QH15. Effective July 1, 2026, this law consolidates and updates the previous Cybersecurity Law and Law on Cyberinformation Security. Organizations operating in Vietnam should assess system, service, data, incident, prohibited-content, cooperation, and sector-specific duties with qualified counsel. See the official government record.
Vietnam Law on Artificial Intelligence 134/2025/QH15. Effective March 1, 2026, with implementing Decree 142/2026/ND-CP effective May 1, 2026. The law uses a human-centered and risk-managed approach, including safety, cybersecurity, transparency, accountability, lifecycle risk, data protection, prohibited uses, and obligations for organizations developing, providing, deploying, or using AI in Vietnam. See the official government record.
Contractual frameworks. Customer security schedules, data-processing agreements, cyber-insurance conditions, platform terms, and sector contracts may impose obligations beyond law. Maintain a requirements register and resolve conflicting commitments before signing.

12. AI, agentic systems, and emerging security standards

NIST AI Risk Management Framework 1.0. A voluntary framework organized around Govern, Map, Measure, and Manage. NIST is revising it, so treat version 1.0 as the published baseline and drafts as drafts. See the NIST AI RMF portal.
NIST AI 600-1: Generative AI Profile. Extends AI RMF with risks and actions specific to generative AI across governance, content provenance, privacy, security, evaluation, and incident management.
ISO/IEC 42001:2023. A certifiable AI management system standard. It governs policies, roles, impact, risk, lifecycle controls, suppliers, monitoring, and improvement; it is not a penetration-testing standard for models.
ISO/IEC 23894. Guidance for AI risk management, useful alongside ISO 42001 and organizational risk processes.
OWASP Top 10 for LLM Applications. An awareness list for risks such as prompt injection, sensitive-information disclosure, supply-chain weaknesses, data and model poisoning, improper output handling, excessive agency, system-prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. Confirm the named edition when creating a control mapping.
OWASP Top 10 for Agentic Applications. Released in late 2025 for systems that plan and take actions through tools. It should complement the application, identity, API, supply-chain, and Zero Trust controls already in this guide. It should not replace them.
MITRE ATLAS. A knowledge base of adversary tactics and techniques against AI-enabled systems. Use it for AI threat modeling, red teaming, and detection planning.
AI red teaming and TEVV. Testing, evaluation, verification, and validation should cover security boundaries, prompt injection, tool authorization, data leakage, unsafe outputs, model and retrieval poisoning, availability, monitoring, and human escalation.
Agent identity and least agency. Give an AI agent its own attributable identity, minimum tool permissions, scoped and short-lived credentials, explicit approval boundaries, output validation, action logs, spend and rate limits, and a reliable kill switch. Never let a model’s text output become authorization by itself.
Content provenance: C2PA. An open technical specification for cryptographically signed content credentials and edit history. It can help establish provenance but does not prove that content is true.
Crypto agility. Inventory algorithms, keys, certificates, protocols, libraries, hardware, and dependent partners so cryptography can be replaced without redesigning the entire system. This is the bridge between today’s controls and post-quantum migration.

How these standards fit together

A mature program usually needs one element from several layers:

Business governance: NIST CSF 2.0, ISO 27001, CIS Controls, COBIT, or a combination.
Detailed controls: NIST SP 800-53, CIS Safeguards, ISO 27002, CSA CCM, and sector requirements.
Architecture: NIST Zero Trust, CISA ZTMM, cloud shared responsibility, identity and data architecture.
Engineering lifecycle: NIST SSDF, OWASP SAMM, ASVS, threat modeling, SLSA, SBOM, and secure release practices.
Technical protocols: TLS, WebAuthn, OAuth/OIDC, SCIM, DNSSEC, email authentication, workload identity, and signed artifacts.
Operations: asset and vulnerability management, ATT&CK-aligned detection, logging, incident response, backups, and exercises.
Assurance: testing, evidence, independent assessments, SOC 2, ISO certification, PCI validation, or sector authorization.
Law and contracts: privacy, cybersecurity, resilience, product, sector, customer, and employment obligations.

Do not create a separate control for every framework sentence. Build a common control set with owners, systems, implementation statements, tests, evidence, exceptions, and review dates. Then map each requirement to that shared control. One strong access-review process can support ISO 27001, SOC 2, NIST, PCI DSS, customer questionnaires, and internal policy without six duplicate procedures.

A practical 12-month roadmap

Months 1 to 3: know what you have

Assign security ownership and executive accountability.
Inventory systems, domains, cloud accounts, identities, data, suppliers, software, and business-critical processes.
Define crown-jewel resources and trust boundaries.
Create a NIST CSF 2.0 Current Profile or CIS IG1 gap assessment.
Fix exposed services, default credentials, unsupported software, missing MFA, and untested backups.
Establish legal and contractual requirement registers.

Months 4 to 6: control access and software change

Deploy phishing-resistant MFA or passkeys for administrators and high-risk users.
Centralize identity lifecycle and remove stale accounts.
Introduce device posture, least privilege, just-in-time administration, and resource-level access.
Adopt ASVS requirements and threat modeling for important applications.
Protect source control and CI/CD; scan secrets and dependencies; generate signed SBOMs.

Months 7 to 9: improve visibility and response

Centralize high-value identity, cloud, application, endpoint, and change logs.
Map priority threats to ATT&CK and test detections.
Use KEV, EPSS, CVSS, exposure, and asset criticality to prioritize remediation.
Write and exercise incident, ransomware, data-breach, and supplier-failure playbooks.
Measure restore time and recovered data against RTO and RPO.

Months 10 to 12: prove and improve

Test control design and operation with evidence.
Conduct scoped penetration tests and recovery exercises.
Close high-risk exceptions or obtain time-bound risk acceptance.
Review supplier evidence and exit plans.
Select certification or attestation only when customers, regulators, or business strategy justify it.
Build next year’s Target Profile from measured gaps and lessons learned.

What good security looks like

Good security is not the organization with the longest policy library. It is the organization that knows its important resources, verifies access, ships controlled changes, notices meaningful anomalies, limits blast radius, communicates clearly, and recovers within business expectations.

Use standards to create that capability. Do not use them to decorate a questionnaire.

If your business needs help turning this map into a realistic roadmap for a website, ecommerce platform, cloud workload, or development process, contact ViWeb. We can help identify the smallest control set that materially reduces risk and can actually be maintained.

FAQ

Is Zero Trust a product or a certification?

Neither. Zero Trust is an architecture and operating model. NIST SP 800-207 defines the principles, while CISA's maturity model and NIST SP 1800-35 help organizations plan and implement them.

Which cybersecurity framework should a small business start with?

Start with CIS Controls v8.1 Implementation Group 1 or a small NIST CSF 2.0 profile. Add OWASP ASVS for web applications, a tested backup and incident plan, phishing-resistant MFA, and the legal requirements that apply to your data and market.

Does ISO 27001 make a company secure?

No certification guarantees security. ISO/IEC 27001 shows that an organization operates a risk-based information security management system within a defined scope. Control quality, technical implementation and continuous improvement still matter.

Is the OWASP Top 10 a complete application security standard?

No. It is an awareness and prioritization document. OWASP recommends ASVS for verifiable application security requirements and SAMM for improving the software security program.

How often should this standards map be reviewed?

Review it at least annually and whenever your architecture, markets, data types or regulatory obligations change. Protocols, threat catalogs, laws and implementation guidance evolve at different speeds.