Compliance & Security Framework FAQ

ISO/IEC 27001 is an international standard for an Information Security Management System (ISMS) — a structured, risk-based approach to protecting information assets. It applies to any organization, regardless of size or industry, that wants a certifiable way to demonstrate its security program is systematic rather than ad hoc.

Certification is a formal, third-party-audited status issued by an accredited certification body after a two-stage audit. "Compliance" without certification means an organization has implemented the standard's requirements internally but hasn't undergone independent verification — most enterprise customers and procurement teams specifically require the certified status, not self-attested alignment.

The 2022 revision consolidated the control set to 93 controls across four themes: organizational, people, physical, and technological. This replaced the older 2013 version's 114 controls across 14 domains, reflecting a restructured, more consolidated approach.

For an organization starting from a reasonably mature security baseline, 6–12 months is typical, covering gap assessment, control implementation, internal audit, management review, and the two-stage external certification audit. Organizations with less mature baselines, or larger/more complex scopes, often take 12–18 months.

A SOC 1 report addresses controls at a service organization that are relevant to a user entity's internal control over financial reporting (ICFR). It's primarily requested by a client's financial statement auditors, not their security or procurement teams.

Type I evaluates whether controls are suitably designed as of a specific point in time. Type II evaluates whether those controls operated effectively over a defined period, typically 6–12 months, and is what most auditors and enterprise clients ultimately require.

Organizations whose services affect a client's financial reporting — payment processing, billing, transaction reconciliation, payroll processing — typically need SOC 1. If the service instead primarily affects security, availability, or data handling without direct financial-reporting impact, SOC 2 is the more relevant report. Many organizations need both.

If your service relies on other vendors (cloud infrastructure, ERP platforms, payment processors) to achieve your control objectives, you must determine whether to use the carve-out method (excluding their controls but disclosing complementary sub-service organization controls) or the inclusive method (incorporating their controls directly into your report).

Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for every SOC 2 report; the other four are selected based on the commitments the organization actually makes to its customers.

Type I assesses control design at a single point in time. Type II assesses operating effectiveness over an observation period, usually 3–12 months. Type II is what most enterprise buyers require before signing a contract.

There's no formal expiration date set by the AICPA, but the practical industry standard is that a report is considered current for about 12 months from the end of its observation period — most customers will request a renewed report annually.

No. SOC 2 is an attestation, not a certification — a licensed CPA firm issues an opinion on your controls, but there's no accredited certification body or certificate. It's still an independently verified, audited report, just structured differently from ISO 27001.

ISO 27018 provides supplementary guidance specifically for protecting personally identifiable information (PII) in public cloud environments, covering consent, transparency, and PII processor obligations that go beyond ISO 27001's general information security controls.

No — it's an extension standard, assessed alongside an existing ISO 27001 certification. An organization can't be certified to ISO 27018 without also holding ISO 27001 certification covering the same scope.

Cloud service providers and PII processors handling customer personal data at scale, particularly those serving customers with strong data privacy expectations or regulatory obligations (GDPR-adjacent contexts especially), benefit most from demonstrating this additional layer of privacy-specific control.

ISO/IEC 42001 is the first international certifiable standard for an AI Management System (AIMS) — a governance framework for how organizations develop, deploy, and monitor AI systems responsibly, covering risk management, data governance, and human oversight.

An ISMS (ISO 27001) manages information security risk broadly. An AIMS (ISO 42001) manages risks specific to AI systems — model bias, explainability, training data provenance, and AI-specific human oversight — which an ISMS doesn't address at all.

Both. The standard applies to organizations that develop, provide, or use AI products or services — a company deploying third-party AI models still has AI-related governance obligations under a scoped AIMS, not just companies training their own models.

ISO 42001 is a voluntary, certifiable management system standard. The EU AI Act is binding law with its own legally defined risk tiers. An ISO 42001 AIMS provides strong supporting governance infrastructure for EU AI Act compliance, but certification alone doesn't satisfy the Act's specific conformity assessment and documentation obligations for high-risk systems.

HITRUST CSF is a harmonized security control framework that consolidates requirements from ISO 27001, NIST, HIPAA, PCI DSS, and other frameworks into a single, prescriptive, certifiable control set — originally built for healthcare but used more broadly today.

e1 ("Essentials") is a lighter, 1-year assessment covering foundational cybersecurity hygiene. i1 ("Implemented") is a moderate-assurance, 1-year assessment. r2 ("Risk-based") is the most comprehensive, 2-year certification with the deepest control validation — and the highest cost and effort.

No, though healthcare and healthcare-adjacent organizations (payers, business associates, health tech vendors) remain its primary audience, largely because it's frequently required contractually in that industry. Organizations outside healthcare can pursue it, but the cost premium is usually only justified by explicit customer or contractual demand.

PCI DSS is the Payment Card Industry Data Security Standard, governing any organization that stores, processes, or transmits cardholder data. Version 4.0.1 is the current baseline, with all previously future-dated requirements now mandatory.

Not automatically. Scope depends on where encryption and decryption occur and who controls the cryptographic keys — systems that store encrypted data but retain the ability to decrypt it generally remain in scope. Encryption reduces risk; it doesn't by itself redraw the compliance boundary.

A Self-Assessment Questionnaire (SAQ) is a self-attested checklist available to eligible smaller or lower-risk merchants, with several sub-types (A, A-EP, B, C, D, etc.) depending on payment architecture. A Report on Compliance (ROC) is a full, formal assessment conducted by a Qualified Security Assessor (QSA), typically required for larger transaction volumes or more complex environments.

Annually, at minimum, along with quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) where applicable, and immediately following any material change to the cardholder data environment or payment architecture.

The CRA is EU legislation requiring "products with digital elements" — hardware and software sold into the EU market — to meet secure-by-design, vulnerability handling, and multi-year security update obligations before they can carry a CE mark.

Manufacturers, importers, and distributors of products with digital elements placed on the EU market — a much broader category than typical cybersecurity regulation, covering everything from IoT devices to standalone software products, including many products that never touch regulated data at all.

The regulation entered into force in December 2024. Vulnerability reporting obligations begin in September 2026; most substantive obligations, including conformity assessment and CE marking, apply from December 11, 2027.

The Digital Operational Resilience Act (DORA) is EU financial-sector legislation requiring banks, insurers, investment firms, and payment institutions to manage ICT risk — including risk introduced by their technology vendors — under a standardized resilience framework.

Not directly in most cases, unless designated a "critical" ICT third-party provider. Most US vendors experience DORA indirectly, through contractual and due-diligence requirements their EU financial-sector clients are obligated to impose.

EU financial entities must maintain a register of all ICT third-party arrangements, include specific mandated contract terms (audit rights, exit strategy, incident notification timelines), and assess concentration risk from over-reliance on any single provider.

The Act sorts AI systems into risk tiers — unacceptable (banned), high-risk, limited-risk (transparency obligations), and minimal-risk — with obligations scaling based on the system's classification rather than applying uniformly to all AI.

Annex III lists specific categories including biometric identification, critical infrastructure management, education access/scoring, employment and worker management decisioning, access to essential services (including credit scoring), law enforcement, migration/border control, and administration of justice.

Yes — it applies to any provider or deployer placing an AI system on the EU market or whose AI system's output is used within the EU, regardless of where the company is headquartered.

NIST CSF 2.0 is a voluntary, non-prescriptive framework for managing cybersecurity risk, organized around outcome-based functions rather than specific technical controls — designed to be usable by organizations of any size or sector.

No. There is no accredited certification against NIST CSF. Organizations self-assess maturity against its functions and categories, often using it as a common language to map onto other frameworks like ISO 27001 or SOC 2 rather than as a standalone attestation target.

Govern, Identify, Protect, Detect, Respond, and Recover. "Govern" was added in the 2.0 revision as a standalone function, elevating cybersecurity governance and risk management strategy to the same level as the original five operational functions.

AI security training is a structured programme that builds threat awareness and defensive skills for working with AI and LLM systems — covering adversarial machine learning, prompt injection attacks, model access control failures, AI supply chain risks, and the governance obligations of the EU AI Act, NIST AI RMF, and ISO 42001. It is delivered as role-specific modules for security teams, developers, and executives.

Three audience groups benefit most: security analysts who need to assess and respond to AI-layer threats; developers who build and integrate LLM features and must understand OWASP LLM Top 10 risks; and executives who govern AI risk, evaluate AI disclosures, and are accountable for EU AI Act obligations. Role-specific tracks ensure each group learns what is directly applicable to their responsibilities.

EU AI Act Article 4 requires member states to promote AI literacy, and operators of high-risk AI systems must ensure staff have sufficient AI competency — trained, documented, and auditable. AI security training that covers EU AI Act obligations provides both the competency and the documentation trail auditors expect.

The OWASP LLM Top 10 module covers all ten risk categories — from prompt injection (LLM01) and insecure output handling (LLM02) through training data poisoning (LLM03), model denial of service (LLM04), supply chain vulnerabilities (LLM05), sensitive information disclosure (LLM06), insecure plugin design (LLM07), excessive agency (LLM08), overreliance (LLM09), and model theft (LLM10) — with hands-on scenario exercises for each.

Conventional security awareness focuses on phishing email recognition, password hygiene, and social engineering — none of which covers the adversarial ML techniques, prompt injection patterns, or AI governance obligations that AI security training addresses. AI threats require dedicated curriculum: prompt injection simulation labs, adversarial ML scenario walkthroughs, and deepfake social engineering awareness that email-based phishing simulations do not cover.