Frequently Asked Questions

Controls are the specific procedures, policies, or technical safeguards that your organization has in place to satisfy the SOC 2 framework. They are organized under Trust Service Criteria (TSC):

• Security (CC) — always required
• Availability
• Confidentiality
• Processing Integrity
• Privacy

Your audit will examine a list of controls defined by you (often drawn from your GRC platform)—only controls on that list will be tested. Controls that are genuinely out of scope can be deactivated in your GRC tool (if applicable); you should coordinate with your CSM or Audit Project Lead first.

• SOC 1 — Examines primarily Internal Controls over Financial Reporting (ICFR). Relevant if your service directly affects a customer's financial statements.
• SOC 2 — Examined more general security related controls as mapped to the AICPA Trust Services Criteria (TSCs). The standard for technology and SaaS companies.
• SOC 3 — A public-facing, simplified summary of a SOC 2. Does not include detailed test results. Not all companies choose to produce one.

"Audit period," "observation period," and "audit window" refer to the same thing: the date range during which controls should be operating effectively and evidence is being collected to present to the auditors. In other words, these are the dates being assessed in the audit. This date range appears in the final report and is what customers evaluate when assessing the currency of your compliance. Communicate any major control changes, new systems, or personnel changes during this period to your project lead.

Yes, within limits. The minimum is 90 days. For annual renewals, the standard is 12 months, but adjustments can be discussed if there is a business need—such as aligning with a fiscal year end or a specific customer requirement. Windows exceeding 12 months are not standard, but acceptable. The key thing is to show continuous compliance, so there shouldn’t be any gaps between audit periods. Any changes to the window must be agreed upon with your project lead before the period begins.

‍

A Type I report is a point-in-time assessment confirming your controls are suitably designed as of a specific date. A Type II report covers a period of time — typically 6 to 12 months — and tests whether your controls actually operated effectively throughout that period. Most enterprise clients and financial institutions require Type II.

‍

A Type I engagement typically takes 6–10 weeks from kickoff to final report. A Type II requires a defined audit period (usually 6–12 months) plus 4–8 weeks of fieldwork and reporting afterward. We provide a precise timeline in your engagement letter before work begins.

‍

Not required, but strongly recommended if this is your first SOC 1 audit. A readiness assessment identifies helps identify additional controls and gaps before your auditors do — giving you time to remediate without delaying your report. Organizations that skip readiness are significantly more likely to receive qualified opinions or exceptions.

‍

We work with service organizations of all sizes — from 2-person fintech startups pursuing their first SOC 1 to publicly traded companies managing annual renewals. Our approach is scoped to your complexity, not your headcount.

Primarily access to your control owners for walkthroughs, and the ability to pull evidence (logs, approvals, configurations) on request. We design our evidence requests to minimize burden — most clients report fewer than 20 hours of internal effort for a typical Type II engagement.

‍

Yes. We offer audit and advisory services across SOC 2, ISO 27001, HIPAA, PCI-DSS, NIST CSF, and CMMC. Many of our clients run concurrent SOC 1 and SOC 2 engagements to maximize control overlap and reduce total audit effort.

Security (Common Criteria) is always required. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — depend on your service and what your clients care about. We help you scope the right combination in week one, so you're only tested on what's genuinely relevant to your environment.

A Type I typically takes 6–8 weeks from kickoff to final report. A Type II requires a defined audit period (usually 3–12 months) plus 6–8 weeks of fieldwork and reporting. We provide a precise timeline in your engagement letter before any work begins.

Not required, but strongly recommended — especially if this is your first SOC 2. A readiness assessment catches control gaps before your auditors do, giving you time to remediate on your schedule. Organizations that skip it are significantly more likely to receive exceptions or a qualified opinion.

We design engagements to minimize internal burden. We manage evidence collection, documentation, and auditor coordination. Most clients report fewer than 20 hours of internal effort for a full Type II engagement — far less than the 100+ hours typically required when navigating an audit without dedicated support.

Yes — and it's often more efficient. Many controls overlap across frameworks, so running concurrent engagements reduces the total audit burden on your team. We regularly manage combined SOC 1 + SOC 2, SOC 2 + ISO 27001, and SOC 2 + HIPAA programs for the same client.

‍

A SOC 3 report is a publicly distributable summary of a SOC 2 audit. It's based on the same Trust Services Criteria and conducted by the same independent CPA firm — but the report itself contains only the auditor's opinion and management's assertion, with no detailed control descriptions, testing procedures, or exception findings. Because it omits sensitive operational details, it can be freely shared with anyone: published on your website, included in sales materials, and handed to partners or investors without an NDA.

‍

Yes — a SOC 3 requires a completed SOC 2 Type II audit as its foundation. You cannot obtain a SOC 3 without an underlying SOC 2. The most efficient approach is to pursue them simultaneously: we conduct one SOC 2 Type II audit and issue both reports at the end. If you already have a current SOC 2, we can issue the SOC 3 from that existing report without a full re-engagement.

No. SOC 3 reports are always Type II — they must cover a defined period and assess the operating effectiveness of controls over time. There is no point-in-time (Type I) option for SOC 3. This is one key difference from SOC 2, which is available in both Type I and Type II formats.

SOC 2 is restricted — you can only share it with clients, prospective clients, and parties with a legitimate need, and typically under NDA. This limits its use in marketing, on your website, or with anyone outside a formal sales process. SOC 3 removes that restriction. It lets your marketing team publish your compliance posture publicly, lets your sales team share it freely without legal review, and allows you to place a compliance seal on your website that answers security questions before they're asked.

No — and it's important to understand this distinction. Enterprise procurement teams, security reviewers, and vendor onboarding processes typically require the full SOC 2 report with all its detailed control documentation. SOC 3 supplements your SOC 2 Type II — it doesn't replace it. Think of SOC 3 as top-of-funnel trust building, and SOC 2 as the in-depth documentation that closes the deal.

If you already have a current SOC 2 Type II, adding a SOC 3 is significantly less expensive than a full new engagement — since the underlying audit work is already complete. The cost primarily covers the CPA firm's time to draft the SOC 3 opinion and management's assertion in the appropriate public format. We provide transparent, fixed-fee pricing for all engagements. Contact us with your existing SOC 2 details and we'll give you a precise quote.

Yes, if you process the personal data of EU residents — regardless of where your company is located. Article 3 of GDPR extends its territorial scope to any organization that offers goods or services to EU residents, monitors their behavior (including through website analytics and cookies), or processes their data. Many US companies are surprised to learn they are subject to GDPR simply because they have EU website visitors or EU customers. Data protection authorities have fined non-EU companies and this enforcement is increasing.

A data controller determines the purposes and means of processing personal data — they decide why and how data is collected and used. A data processor processes personal data on behalf of a controller. The same organization can be a controller for some activities and a processor for others. Controllers bear the highest level of GDPR responsibility, including accountability for their processors' compliance. Processors must comply with Article 28 requirements and enter into formal data processing agreements with every controller they serve.

A Data Protection Impact Assessment (DPIA) is legally required under Article 35 when processing is "likely to result in a high risk" to individuals' rights and freedoms. This includes large-scale processing of special category data (health, biometric, racial or ethnic origin), systematic monitoring of publicly accessible areas, automated decision-making with significant legal effects, new technologies that create significant privacy risks, and processing that involves profiling. We help you determine whether a DPIA is required for your specific processing activities and guide you through the full process.

GDPR Chapter V restricts transfers of personal data to countries outside the EU/EEA unless adequate protection is ensured. Approved transfer mechanisms include: adequacy decisions (countries the EU has deemed adequate — including the US-EU Data Privacy Framework), Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), and derogations for specific situations. Transfers without a valid mechanism are one of the most commonly cited GDPR violations and a frequent source of significant fines. Our international transfer review assesses all your cross-border data flows and ensures appropriate mechanisms are in place.

Article 28 requires that every arrangement between a controller and processor be governed by a binding data processing agreement that specifies: the subject matter, duration, nature and purpose of processing; the type of personal data and categories of data subjects; the obligations and rights of the controller; and that the processor acts only on documented instructions. The agreement must also address sub-processor management, confidentiality obligations, security measures, assistance with data subject rights and breach notification, deletion/return of data on contract end, and demonstration of compliance. Non-compliant DPAs are one of the most common findings in our processor assessments.

ISO 27001 provides a framework for information security management that supports GDPR's integrity and confidentiality requirements (Article 5(f)) and the technical and organizational security measures required by Article 32. ISO 27018 specifically addresses GDPR's requirements for data processors handling personal data in the cloud, with controls that map directly to Article 28 obligations. Pursuing ISO 27001 and 27018 alongside a GDPR assessment significantly reduces total compliance effort through control reuse — and the certifications provide independently verified evidence of compliance that regulators and enterprise clients find more credible than self-assessment alone.

GDPR requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach (Article 33), unless the breach is unlikely to result in risk to individuals. If the breach is likely to result in high risk, affected data subjects must also be notified without undue delay (Article 34). Your breach response plan should include: containment procedures, an internal assessment of risk and scope, documentation of the breach and response, notification to the supervisory authority, and notification to data subjects where required. We help organizations build and test breach response procedures so the 72-hour window is manageable — not a crisis.

The CCPA (California Consumer Privacy Act) was the original law, effective January 1, 2020. The CPRA (California Privacy Rights Act), passed by voters in November 2020, significantly expanded the CCPA — adding new consumer rights (right to correct, right to limit sensitive PI), creating the California Privacy Protection Agency (CPPA) to enforce the law, establishing employee data protections, strengthening opt-out requirements, and introducing new rulemaking authority. Most CPRA provisions took effect January 1, 2023. Today, "CCPA compliance" refers to compliance with the CCPA as amended and expanded by the CPRA.

Yes, if you do business in California — which generally means you collect personal information from California residents, including through a website accessible to Californians. Many companies based in Texas, New York, or outside the US entirely are subject to CCPA because they sell to California residents. The revenue threshold ($26.625M as of 2025) applies to global annual gross revenue, not just California revenue. If you're unsure whether CCPA applies, our coverage determination service can give you a definitive answer quickly.

Businesses must respond to verifiable consumer requests within 45 days of receipt. If reasonably necessary, you can extend this by an additional 45 days (90 days total), but you must notify the consumer of the extension within the initial 45-day period. Businesses must also maintain documentation of all consumer requests and their responses for 24 months. Setting up robust workflows, verification procedures, and tracking systems before requests arrive is essential — the timelines are strict and the documentation requirement is easily overlooked.

A service provider is an entity that processes personal information on behalf of a business under a written contract — and that contract must include specific CCPA provisions. Required terms include: processing personal information only for the specified business purpose; prohibiting selling or sharing the personal information; requiring the service provider to assist with consumer rights requests; and imposing the same restrictions on any sub-processors. If your vendor agreements don't include these terms, you remain liable for how that vendor uses the personal information you've shared with them. Service provider agreement review is one of the most common findings in our CCPA assessments.

Dark patterns are user interface design choices that make it difficult for consumers to exercise their privacy rights — for example, burying the "Do Not Sell" link in small text, requiring multiple clicks to opt out while allowing one click to opt in, or using confusing language that misleads consumers about the effect of their choice. The CPPA explicitly prohibits dark patterns and has made enforcement of UI design choices a priority. Our privacy notice reviews specifically check for dark patterns that could trigger CPPA regulatory action, including consent mechanisms, cookie banners, and opt-out flows.

CCPA and GDPR share many common elements — both require transparency, data subject rights, and documented legal bases for processing — but they differ in important ways. GDPR requires a legal basis for every processing activity; CCPA focuses primarily on disclosure and opt-out rights. GDPR's consent requirements are stricter; CCPA gives consumers an opt-out right rather than requiring opt-in consent for most processing. Both have breach notification requirements. Johanson Group designs combined CCPA + GDPR programs that satisfy both simultaneously — sharing documentation, data mapping, and control structures across both frameworks to reduce total compliance cost significantly.

Yes, if your software accesses, stores, or transmits protected health information on behalf of a covered entity, you are a Business Associate under HIPAA — and directly liable for compliance. The HITECH Act extended direct HIPAA liability to business associates in 2013. SaaS platforms, EHR vendors, telehealth services, cloud storage providers, billing software, and health analytics tools are all common business associates. You need a signed Business Associate Agreement with every covered entity client and must comply with the Security Rule in full. This is one of the fastest-growing areas of OCR enforcement.

A Business Associate Agreement (BAA) is a legally required contract between a covered entity and any vendor or contractor that creates, receives, maintains, or transmits PHI on the covered entity's behalf. The BAA must specify permitted uses and disclosures of PHI, require the business associate to implement Security Rule safeguards, mandate breach notification within 60 days of discovering a breach, and require the same obligations to flow down to subcontractors. Operating without a signed BAA is one of the most commonly cited HIPAA violations and a frequent focus of OCR enforcement. BAAs do not have a statutory expiration date but should be reviewed annually.

Yes — a Risk Analysis is explicitly required by the HIPAA Security Rule (45 CFR 164.308(a)(1)) and is the first thing OCR examines during a compliance review or investigation. It must be a thorough, accurate, and current assessment of potential risks and vulnerabilities to all ePHI your organization creates, receives, maintains, or transmits. It must assess the likelihood and impact of each risk, and the results must feed into a documented Risk Management Plan. Failure to complete an adequate Risk Analysis is the single most commonly cited violation in OCR enforcement actions. It must be updated whenever there are significant changes to your environment.

HIPAA compliance means your organization's policies, procedures, and controls meet HIPAA requirements. HIPAA attestation is a formal, third-party report from an independent auditor documenting that assessment — available as an examination engagement or a compliance attestation. Attestation provides covered entities, their clients, and regulators with independent, credentialed evidence of your compliance posture. For business associates, a HIPAA attestation report is increasingly required during enterprise vendor onboarding — particularly for healthcare systems, health plans, and federal healthcare programs. It goes significantly beyond self-attestation or compliance questionnaires.

HIPAA and SOC 2 address overlapping but distinct concerns. HIPAA is a legal requirement for organizations that handle PHI; SOC 2 is a voluntary attestation framework for service organizations more broadly. They share significant control overlap — access controls, audit logging, incident response, risk assessment, encryption, and vendor management all appear in both. Many health tech companies pursue both simultaneously: a HIPAA attestation satisfies healthcare-specific regulatory and client requirements, while a SOC 2 Type II report satisfies broader enterprise security expectations. Running them concurrently with Johanson Group typically reduces total cost and effort significantly, since documentation and evidence collection are largely shared across both engagements.

OCR (Office for Civil Rights at HHS) investigations are typically triggered by a breach report, a complaint from a patient or workforce member, or selection for the periodic audit program. During an investigation, OCR will request documentation of your Risk Analysis and Risk Management Plan, policies and procedures, training records, BAAs, breach notification records, and evidence of technical safeguard implementation. Organizations that can quickly produce thorough, current documentation fare significantly better — both in terms of finding scope and financial penalties. OCR cooperation is considered a mitigating factor in penalty calculations. Organizations without documented compliance programs regularly receive corrective action plans and penalties that proper preparation would have avoided or reduced.

NIST 800-53 is the comprehensive control catalog for federal information systems — 1,196 controls across 20 families in three impact baselines. It applies to federal agencies, cloud providers seeking FedRAMP, and operators of federal systems. NIST 800-171 is a targeted subset of 800-53 — 110 requirements across 14 families — designed to protect CUI in non-federal systems. It applies to defense contractors and anyone handling CUI under DFARS 252.204-7012. The key practical difference: 800-53 is broader with mandatory third-party assessment for federal systems; 800-171 is focused, primarily self-assessed, and produces an SPRS score for DoD reporting.

Controlled Unclassified Information (CUI) is information the US government creates or possesses that requires safeguarding per law, regulation, or government-wide policy — but is not classified. CUI categories include defense technical data, export controlled information (ITAR/EAR), law enforcement sensitive data, federal contract information, and privacy data. If you work on DoD, civilian agency, or federal grant contracts and your systems contain any sensitive government information, you likely handle CUI. The CUI Registry (cui.archives.gov) lists all approved categories. A CUI identification and scoping engagement is the essential first step for any organization uncertain about their obligations.

The SPRS score is a numerical representation of your NIST 800-171 compliance — starting at 110 with point deductions for deficient requirements. Under DFARS 252.204-7019 and 252.204-7020, all contractors subject to DFARS 252.204-7012 must self-assess and submit their score to the SPRS database before contract award or renewal. A score below 110 is acceptable with a POA&M — but an inaccurate or falsely inflated score can constitute a False Claims Act violation. Third-party assessment by Johanson Group produces a defensible, documented score with full evidence trail that withstands government scrutiny.

As of mid-2026, NIST 800-171 Revision 2 (110 requirements, 14 families) remains the mandatory standard for DFARS 252.204-7012 and CMMC Level 2. NIST published Rev 3 in May 2024 — restructured to 97 requirements across 17 families — but DoD confirmed through Class Deviation 2024-O0013 that Rev 2 remains the compliance standard until further notice. Comply against Rev 2 for current obligations while familiarizing with Rev 3 for an eventual transition. We advise clients on both and can assess your Rev 2 posture while identifying your Rev 3 gap.

CMMC Level 2 is essentially NIST 800-171 Rev 2 with a third-party assessment requirement. All 110 Rev 2 requirements map directly to CMMC Level 2 practices — satisfying 800-171 satisfies CMMC Level 2 from a control perspective. The key difference is the assessment model: 800-171 allows self-assessment; CMMC Level 2 requires independent assessment by an accredited C3PAO for contracts involving critical defense information. Johanson Group's 800-171 assessments are structured to serve both purposes — satisfying SPRS reporting and building the foundation for CMMC Level 2 readiness.

FedRAMP is based on NIST 800-53. FedRAMP Moderate authorization requires the 800-53 Moderate baseline (287 controls); FedRAMP High requires the High baseline (370 controls). If you are a cloud service provider seeking to sell to federal agencies through FedRAMP, you need 800-53. NIST 800-171 applies when you are a contractor handling CUI in your own internal non-federal systems — not to the cloud service you offer to agencies. A company can need both: internal systems handling CUI need 800-171 compliance, while the cloud service offered to agencies needs FedRAMP using 800-53.

Yes, PCI DSS may still apply, but the scope depends on how payment data is handled and your role in the payment ecosystem.For merchants, fully outsourcing payment processing to a PCI DSS-compliant provider can significantly reduce PCI DSS scope. For example, if customers enter payment card data directly into the processor's hosted payment page and your systems do not store, process, or transmit cardholder data, you may qualify for a simplified validation approach, such as SAQ A. However, if your website can affect the security of the payment transaction, for example, through scripts, embedded payment content, redirects, or other mechanisms, or if cardholder data touches your environment in any way, your PCI DSS scope and validation requirements may increase.

For service providers, the situation is different. Service providers do not qualify for merchant self-assessment questionnaires such as SAQ A or SAQ A-EP. Depending on eligibility and reporting requirements, service providers generally validate compliance using the SAQ D for Service Providers or a Report on Compliance (ROC).Determining the correct scope and validation method is one of the most commonly misunderstood aspects of PCI DSS. It is also one of the first things we help clients clarify during an engagement.

A Report on Compliance (ROC) is a formal PCI DSS assessment report typically completed by a Qualified Security Assessor (QSA) or Internal Security Assessor (ISA), depending on the entity’s validation requirements. A ROC provides a detailed record of the assessment scope, testing performed, evidence reviewed, and the entity’s compliance status for applicable PCI DSS requirements.A Self-Assessment Questionnaire (SAQ) is a PCI DSS validation tool used by eligible organizations to assess and report their own compliance. Different SAQs apply to different payment environments and entity types.For merchants, SAQs such as SAQ A, SAQ A-EP, SAQ B, SAQ C-VT, SAQ P2PE, and SAQ D for Merchants may apply depending on how payment data is accepted, processed, stored, or transmitted.

‍SAQ A and SAQ A-EP are merchant-only validation paths.For service providers, the SAQ path is different. Service providers do not use SAQ A or SAQ A-EP. If a service provider is eligible to self-assess, the applicable SAQ is generally SAQ D for Service Providers. Otherwise, the service provider may need to complete a ROC.Both a ROC and an SAQ are typically accompanied by an Attestation of Compliance (AOC), which summarizes the validation result and is submitted to the requesting organization, such as an acquiring bank, payment brand, customer, or compliance program manager.Choosing the wrong validation path, or completing the right form with the wrong scope, is one of the most common PCI DSS reporting mistakes.

If your organization does not meet applicable PCI DSS requirements, your ROC or SAQ generally cannot be completed as compliant until the deficiencies are remediated, retested, and properly documented. In some cases, your acquiring bank, payment brand, customer, or compliance program may require a remediation plan, milestone tracking, or additional validation before accepting your attestation.

A cardholder data breach is more serious. Depending on the circumstances, you may be required to notify your acquirer, payment brands, customers, regulators, or affected individuals; engage a PCI SSC-listed Payment Card Industry Forensic Investigator (PFI); remediate the root cause; complete additional validation; and absorb costs related to investigation, card replacement, fraud recovery, legal response, increased fees, or contractual assessments.

Public discussions of PCI-related penalties often cite ranges such as $5,000 to $100,000 per month, but actual consequences vary by payment brand, acquirer, contractual obligations, breach facts, transaction volume, prior compliance status, and remediation response. In some cases, an organization may also face increased validation requirements, heightened monitoring, or restrictions on its ability to process payment cards.

A mature, documented PCI DSS program does not eliminate breach risk, but it can reduce the likelihood of a breach, improve incident response, and help demonstrate that the organization took reasonable steps to protect account data.

PCI DSS and SOC 2 are complementary frameworks, but they serve different purposes.

‍PCI DSS is a contractual security standard that applies to organizations that store, process, transmit, or can impact the security of payment card data. It is highly prescriptive and focuses specifically on protecting account data and payment environments.

‍SOC 2 is an independent attestation based on the AICPA Trust Services Criteria. While not mandated by the payment brands, many enterprise customers require SOC 2 reports as part of vendor due diligence and security reviews. SOC 2 evaluates the effectiveness of controls related to security and, when applicable, availability, processing integrity, confidentiality, and privacy.

The two frameworks cover many similar topics, including access controls, encryption, logging and monitoring, incident response, change management, and vendor oversight. However, PCI DSS provides detailed technical and operational requirements for payment environments, while SOC 2 allows organizations greater flexibility in how they design and operate their controls.

Organizations that process payment card data and sell to enterprise customers often pursue both. PCI DSS helps satisfy payment brand, acquirer, and customer requirements related to account data security, while SOC 2 helps demonstrate a mature security program during customer onboarding and vendor risk assessments.

When planned together, many policies, procedures, controls, and evidence artifacts can be leveraged across both efforts, reducing duplication and improving overall compliance efficiency.

ISO/IEC 27001 is the internationally recognized standard for Information Security Management Systems (ISMS). It's published by the International Organization for Standardization and specifies requirements for establishing, implementing, maintaining, and continuously improving a systematic approach to managing information security risks. You likely need it if enterprise clients are requiring it during vendor onboarding, if you're selling into European or APAC markets, if government or defense contracts require it, or if you want to demonstrate security maturity to investors and partners with a globally recognized credential.

SOC 2 is a US-based attestation report issued by a CPA firm under AICPA standards — it produces a restricted report, not a certificate. ISO 27001 is an internationally recognized certification issued by an accredited certification body — it produces a certificate that can be publicly displayed. SOC 2 is the default expectation for US enterprise sales; ISO 27001 is often required for international clients and European markets. The frameworks share significant control overlap, so running both concurrently is often the most efficient path. Organizations that are SOC 2 compliant often find they are 70–80% of the way to ISO 27001 from a controls perspective.

‍

The time required to achieve ISO 27001 certification depends largely on an organization's readiness for certification. Once an organization is ready, the certification process typically includes a Stage 1 Audit followed by a Stage 2 Audit. Audit duration is determined by factors such as organizational size, number of locations, and the complexity of the certification scope.

We can provide an estimated certification timeline after reviewing your organization's scope and certification requirements.

The Statement of Applicability (SoA) is one of the most important documents in an ISO 27001 engagement. It lists all 93 Annex A controls from ISO 27001:2022, documents which controls are applicable to your organization, whether each is implemented, and the justification for including or excluding each one. Auditors use the SoA as a primary reference during Stage 1 and Stage 2. A poorly constructed SoA is one of the most common reasons Stage 1 audits identify issues.

The ISO 27001:2022 update restructured Annex A from 114 controls across 14 control objectives to 93 controls across 4 themes: Organizational, People, Physical, and Technological. It added 11 new controls including threat intelligence, information security for cloud services, data masking, data leakage prevention, web filtering, and secure coding. 57 controls were merged, 23 renamed, 35 remained the same, and 1 was split. The 2022 version also introduced 5 control attributes for better categorization and aligns more closely with ISO/IEC 27002:2022 and other modern management system standards.

The cost of ISO 27001 certification depends on factors such as organizational size, number of personnel, locations within scope, and the complexity of the activities covered by the ISMS. Audit duration is determined in accordance with established certification requirements and directly influences certification costs.

We provide customized quotations based on your organization's specific certification scope and requirements. Contact us to discuss your needs and receive a proposal.

ISO 27001 certification is valid for three years, but it requires annual surveillance audits in years 1 and 2 to confirm continued compliance and ongoing ISMS improvement. Surveillance audits are lighter than the initial certification audit — they focus on specific areas of the ISMS rather than a full review. In year 3, a full recertification audit renews the certificate for another three-year cycle.

Yes. ISO 27001 can be applied to organizations with fully remote, hybrid, or office-based workforces. The organization must demonstrate that information security risks associated with remote work are appropriately identified and controlled. Many modern SaaS and technology companies achieve certification while operating entirely remotely.

Yes. Organizations may determine that certain Annex A controls are not applicable based on their scope, activities, technology, and risk assessment results. Any excluded controls must be justified and documented in the Statement of Applicability (SoA). Exclusions cannot be used to avoid addressing relevant risks.

Certified organizations are responsible for notifying Johanson Group of significant changes that may affect their certified management system or certification scope. Examples include:

• Changes to the organization's legal name
• Changes to the organization's registered or certified address
• Addition or closure of locations within the certification scope
• Significant changes to the scope of certification
• Mergers, acquisitions, or ownership changes
• Significant organizational restructuring
• Major changes to products, services, or activities covered by the certification
• Significant changes affecting the effectiveness of the management system

Organizations should communicate these changes as soon as possible so that Johanson Group can determine whether additional review activities, audits, or updates to certification records are required.

Organizations must notify Johanson Group whenever significant changes occur that could affect the certified management system or the scope of certification. Examples include changes to the organization's name, addresses, locations, scope, ownership, or key business activities.

Early notification allows Johanson Group to assess the impact of the change and determine whether additional review activities, special audits, or certificate updates are necessary. Delaying notification may affect the organization's ability to maintain accurate certification records.

ISO/IEC 27017 and ISO/IEC 27018 are extensions to an ISO/IEC 27001-certified Information Security Management System (ISMS). Organizations typically pursue them alongside ISO/IEC 27001 or add them to an existing ISO/IEC 27001 certification.

ISO 27017 focuses on cloud security controls — particularly the shared responsibility model between cloud service providers and their customers, virtual environment security, and cloud-specific operational controls. ISO 27018 focuses specifically on the protection of Personally Identifiable Information (PII) processed in cloud environments — covering consent, data retention, disclosure restrictions, and privacy rights. Most organizations pursuing cloud certification pursue both, since they address different but complementary aspects of cloud risk.

ISO 27018 certification supports GDPR compliance — particularly Article 28 obligations for data processors — but it does not guarantee full GDPR compliance on its own. GDPR is a legal regulation with broad organizational requirements that go beyond technical controls; ISO 27018 addresses the PII processing aspects in cloud environments. That said, ISO 27018 certification provides documented, auditor-verified evidence of cloud PII controls that regulators and enterprise clients specifically look for when assessing GDPR compliance posture.

If you already hold an ISO 27001 certification, adding 27017 and/or 27018 as extensions typically takes 2–4 months depending on how many cloud-specific control gaps need to be addressed first. For organizations pursuing all three standards simultaneously from scratch, total time from engagement kickoff to certification is typically 5–9 months. We provide a precise timeline at the start of your engagement based on your current ISMS maturity and cloud control posture.

Yes — and this is generally the most efficient approach. If you already have ISO 27001 and are ready to add 27017 and/or 27018, we can structure the certification audit to run concurrently with your next ISO 27001 surveillance or recertification audit. This avoids separate audit cycles, reduces total time from your team, and often results in a combined certificate issuance that keeps all three standards synchronized on the same renewal timeline.

ISO 27017 applies to both cloud service providers (CSPs) and cloud service customers — but in different ways. CSPs implement it to demonstrate that their cloud infrastructure meets cloud-specific security controls. Cloud customers use it to ensure they are properly managing their responsibilities within the shared model. In practice, certification is most commonly pursued by CSPs — SaaS, IaaS, and PaaS providers — who need to demonstrate cloud security maturity to their enterprise clients.

ISO/IEC 42001:2023 is the world's first international standard for AI Management Systems — the only certifiable AI governance framework with independent third-party verification. It matters now because AI governance has moved from a voluntary ethics discussion to a business and regulatory imperative. The EU AI Act imposes binding obligations on organizations using AI in the EU; enterprise procurement teams are increasingly requiring evidence of AI governance maturity; and investors are scrutinizing AI risk management as part of ESG assessments. ISO 42001 provides the auditable, internationally recognized proof of responsible AI practice that these stakeholders require.

Any organization that develops or uses AI systems and needs to demonstrate responsible AI governance to external stakeholders. This includes AI technology companies and SaaS vendors whose products use AI; enterprises using AI in high-stakes decisions (HR, lending, healthcare, public services); organizations subject to EU AI Act obligations; companies selling AI-enabled products into regulated industries or international markets; and public sector organizations deploying AI in citizen-facing services. You do not need to be an AI company — any organization deploying AI in its operations can and should consider ISO 42001.

The NIST AI Risk Management Framework (AI RMF) is a voluntary framework for AI risk management — it provides structured guidance but is not certifiable and does not result in independent third-party verification. ISO 42001 is a certifiable management system standard — it produces an independently audited certificate from an accredited certification body that provides verifiable, globally recognized proof of your AI governance posture. Many organizations use NIST AI RMF for internal self-assessment and use ISO 42001 as the certifiable standard that provides external assurance. The two frameworks have significant conceptual overlap and can be pursued complementarily.

No — ISO 42001 can be pursued independently of ISO 27001. The two standards address different domains: ISO 27001 governs information security; ISO 42001 governs AI management specifically. However, if you already have ISO 27001, adding ISO 42001 is significantly more efficient — the standards share the same high-level structure (Annex SL), and management system elements like internal audit, management review, and documentation control can be integrated rather than duplicated. ISO 42001 Annex D provides explicit integration guidance for organizations combining it with other ISO management system standards.

ISO 42001 certification provides substantial support for EU AI Act compliance — but it is not a complete substitute for Act compliance on its own. The EU AI Act imposes specific technical, procedural, and registration obligations that vary by risk tier and go beyond what ISO 42001 covers. However, ISO 42001 controls map directly to many EU AI Act requirements — particularly risk assessment (Clause 8 and Annex A.5), technical documentation (Annex A.11), transparency (Annex A.8), human oversight (Annex A.9), and post-market monitoring (Clause 9). Johanson Group designs AIMS programs that address both ISO 42001 and EU AI Act obligations concurrently, eliminating duplicated effort.

ISO 42001 requires documented information supporting the establishment, implementation, operation, monitoring, and continual improvement of the AI Management System (AIMS). This typically includes policies, risk assessments, statements of applicability, internal audit records, management review records, impact assessments, and risk treatment plans.

No. You do not need to build your own AI models to pursue ISO 42001. The standard applies to organizations that act as an AI producer, AI provider, AI user, or a combination of these roles. Organizations using third-party AI services such as Microsoft Copilot, ChatGPT, Claude, Gemini, or industry-specific AI tools may still benefit from implementing an AI Management System (AIMS) to govern AI-related risks, responsibilities, and oversight.

A Type I is a point-in-time assessment—it validates that controls are designed and implemented correctly as of a specific date. There is no observation period. It is faster and less intensive than a Type II.

A Type II evaluates whether controls operated effectively throughout the entire observation period. It is more rigorous, more widely accepted by customers, and is the industry standard for ongoing compliance. Many clients complete a Type I first to establish an initial report, then move directly into their Type II observation period.

The observation period (also called the audit window) is the span of time over which your SOC 2 Type II controls are evaluated for operating effectiveness. The AICPA minimum is 90 days (3 months). Most first-year audits run 3–6 months; annual renewals operate on a full 12-month cycle, continuing from when the last period ended so that there is no gap between audit periods.