Are you certified? Why the answer depends on which proof the framework produces
A customer questionnaire asks, "Are you certified?" The honest answer depends on the framework. ISO/IEC 27001 and CMMC end in a certificate issued through accredited bodies, HITRUST ends in a certification issued after an Authorized HITRUST External Assessor's validated assessment, SOC 2 ends in a CPA attestation report, and PCI DSS ends in an assessor's Report on Compliance or Self-Assessment Questionnaire, each with an Attestation of Compliance. HIPAA, the NIST CSF, NIS2, DORA and the GDPR issue no certificate of compliance for the organization, so the right answer there describes what you did and what a regulator could ask for, not a certificate number.
The value of any proof depends on three things: who issued it, what it covers, and whether the customer is allowed to rely on it. A certificate from an accredited body tells the reader that the scope and the certification body's audit were checked against the standard at a point in time, and ISO points readers to the IAF CertSearch database to confirm an accredited certificate. A SOC 2 Type 1 report covers the system description and control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period, so a customer should ask which type they hold and what the period was. A SOC 2 report is generally restricted in use, while a SOC 3 can be distributed freely but carries less detail.
How each framework's proof is issued, by who and for what period
This table compares who issues the proof for each framework, what form it takes, the period it covers and who may run the assessment. Read across a row to see how far a customer can rely on the document, and check the issuer before accepting it.
| Framework | Proof type and issuer | Period covered | Who may assess | Publicly checkable |
|---|---|---|---|---|
| ISO/IEC 27001 | Certificate issued by an accredited certification body after audit | Three-year certification cycle with at least one audit every calendar year | Accredited ISMS certification bodies operating to ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024 | Yes, through the IAF CertSearch database, which ISO points to for accredited certificates |
| SOC 2 | CPA attestation report from a licensed CPA firm | Type 1: suitability of design as of a date. Type 2: operating effectiveness over a period | CPA firms performing AICPA attestation engagements under AT-C 205 | No public register. SOC 3 is a general use report, but a SOC 2 report is generally restricted to specified users |
| PCI DSS v4.0.1 | Report on Compliance or Self-Assessment Questionnaire, each with an Attestation of Compliance on PCI SSC templates | Assessment against v4.0.1 at the time of assessment, with the date recorded on the AOC | Qualified Security Assessor for a ROC. SAQ completed by the entity under its own responsibility | Not through a PCI SSC register for every entity. Certificates are not recognized as validation, so ask for the AOC |
| CMMC Level 2 | Certificate of assessment from a C3PAO, with affirmation by a senior official | Certification assessment, with periodic affirmation under 32 CFR Part 170 | C3PAOs authorized or accredited by The Cyber AB | Confirm the status of the certificate with The Cyber AB and the sponsoring contracting authority |
| HITRUST | Validated assessment report and certification issued after HITRUST quality assurance | Certification period set by the assessment type (e1, i1 or r2), as confirmed in the HITRUST listing | Only Authorized HITRUST External Assessor organizations | Confirm the certification status directly with HITRUST before relying on it |
| HIPAA Security Rule | No certificate. HHS does not endorse or recognize private certifications | Continuous obligation, with documentation evidencing compliance | Not applicable. Compliance is assessed by HHS and is not certified | Not applicable. Customers should ask for a risk analysis and policy evidence instead |
| NIST CSF 2.0 | No certificate. NIST offers no conformity assessment program | Self-declared profile and implementation, reported by the organization | Any party the organization selects, with no NIST accreditation | Not applicable. Ask for the organization's own profile and the evidence behind it |
| NIS2 | No certificate of compliance. National competent authorities oversee compliance | Ongoing obligation, checked through inspections, security audits and scans | National competent authorities, not private assessors | Not applicable. Ask whether the supplier is in scope and what its authority requires |
| DORA | No certification scheme. Competent authorities supervise compliance under Article 50 | Ongoing obligation. The only authority attestation is for a threat-led test under Article 26(7) | Competent authorities supervise. Threat-led testing follows the requirements in Article 26 | Not applicable for general compliance. Ask for the threat-led test attestation where one exists |
What makes one proof worth more than another to a customer
A certificate, an attestation report and a regulator's supervision answer the same customer question in different ways. The cards below describe the factors that decide how much weight a customer should give each one, and what to check before accepting it.
Who issued the proof
A certificate is only as strong as the body that issued it. ISO points buyers to accredited certification bodies, which work to ISO/IEC 17021-1:2015 plus ISO/IEC 27006-1:2024, and the accreditation can be checked in the IAF CertSearch database. A CPA firm issues a SOC 2 report, and a Qualified Security Assessor issues a PCI DSS Report on Compliance. Ask who signed, whether that body holds the accreditation or license the framework requires, and whether the scope names the same entity you are buying from.
Point in time or over time
A SOC 2 Type 1 report covers the system description and whether controls were suitably designed as of a single date. A Type 2 report adds an opinion on whether those controls operated effectively across a period. An ISO certificate proves an audit took place within a three-year cycle, not that controls ran every day. Before relying on any proof, check the date or period it covers and whether anything material changed after it closed.
Scope of systems and services
Every proof states what it covers, and the gap between that scope and your use case is where risk hides. A SOC 2 examination covers the system and services named in management's description, and a PCI DSS assessment covers the cardholder data environment. A certificate may cover only certain sites, products or business units. Compare the in-scope systems, the carve-outs and any subservice organizations against the services you will consume, and ask for the excluded parts in writing.
Who may read the report
Access to a report is part of its value. SOC 2 reports are generally restricted to the service organization, its customers and prospects under agreement, and their auditors, so you may need a signed nondisclosure agreement before receiving one. A SOC 3 report covers the same categories in less detail and is a general use report that can be freely distributed. Expect a public SOC 3 to answer a marketing question, and a full SOC 2 to answer a due diligence question.
Regulator or payment brand recognition
Some proof carries legal or contractual weight because someone with authority accepts it. PCI DSS accepts only the official Report on Compliance or Self-Assessment Questionnaire with its Attestation of Compliance, and the PCI SSC states that certificates are not recognized as validation. HHS does not endorse or recognize private HIPAA certifications, and NIST offers no conformity assessment for the CSF. Check which regulator, payment brand or program office will actually accept the document you plan to provide.
Substitute for your own due diligence
No certificate or report removes your duty to assess a supplier or to run your own compliance program. A SOC 2 report describes controls, it does not decide whether they fit your risk. Under GDPR Article 42, certification does not reduce the controller's or processor's responsibility, and HHS warns that a private certification does not prevent a later violation finding. Use the proof as an input to your review, read the exceptions in the auditor's opinion, and document where your own testing is still needed.
How a SOC 2 report and an ISO certificate differ in what they promise
An ISO/IEC 27001 certificate is issued by an accredited certification body after it audits your information security management system against the standard. ISO does not certify organizations itself. The certification body works to ISO/IEC 17021-1:2015 with ISO/IEC 27006-1:2024, and the certificate lasts through a three-year cycle with at least one audit, surveillance or recertification, in every calendar year. The certificate says the system met the standard at audit time and is kept current by periodic audits. A SOC 2 is different. A CPA issues an examination under AT-C section 205 of the AICPA attestation standards, and the service auditor must obtain written representations from management. The controls are assessed against the 2017 Trust Services Criteria, and management's system description is prepared and evaluated against the 2018 description criteria (DC 200). Ask the vendor which criteria categories are in scope, since security is always included but the other four are optional.
The report type matters as much as the framework. A Type 1 report covers the system description and whether controls are suitably designed as of one date, so it is a snapshot. A Type 2 report adds an opinion on whether those controls operated effectively over a period, which is the view most customers need when they ask whether a vendor's controls actually work day to day. Check the period covered, the dates of the testing and any exceptions the auditor noted. A Type 2 report with a short window or a recent start date tells you less than its title suggests. Note also that the AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026. Those revisions are proposals only, and if adopted they would apply to engagements beginning on or after June 15, 2029, so current reports still follow the existing standards.
Neither proof is stronger in general. An ISO certificate suits a customer that wants a publicly searchable, third-party certification of a management system across the whole organization, and the IAF CertSearch database is the place to verify it. A SOC 2 Type 2 suits a customer that wants evidence of how specific services and controls performed over time, and its scope is set by the system described in the report. Before you request either document, confirm the certification body, the accreditation status, the scope statement, the report period and who is permitted to use the report, because SOC 2 use is generally restricted while a SOC 3 is a general use report.
How to confirm which proof a customer will accept
This sequence turns a vague request for certification into a written answer about which proof the customer accepts, who issued it, whether it covers the right services and period, and which controls remain the customer's own responsibility. The output is a short proof record that sales, security and compliance can all point to.
Pull the exact wording from the contract
Start with the words the customer actually used in the contract, the security schedule or the questionnaire, and copy them into one proof record without paraphrasing. Ask the customer's security or procurement contact which framework or report they mean when they say certified, compliant or attested. The step is done when every requirement is quoted verbatim and each has a named owner on both sides.
Classify the proof type requested
For each requirement, decide whether the customer asks for a certificate from an accredited body, an attestation report from a CPA, an assessor report with an attestation of compliance, regulator supervision, or evidence that controls exist. Note that some frameworks have no certificate at all, so a request for one usually needs a different answer, such as a mapped control set or a self-assessment. The output is a single classification per requirement, confirmed in writing with the customer.
Verify the issuer's accreditation
Where the proof is a certificate, check the issuing body's accreditation and the certificate's status in the official database for that scheme. For ISO/IEC 27001 certificates, ISO points to the IAF CertSearch database, so confirm the certification body, the scope statement and the current status there rather than relying on a PDF the supplier sends. The step closes with a saved screenshot or record of the lookup, dated and linked to the proof record.
Confirm the report period and scope
For SOC 2 and similar attestation reports, check whether the report is Type 1 (design as of a date) or Type 2 (operating effectiveness over a period), and whether the period covers the months the customer's data or service is in use. Compare the system description and the in-scope services with the services the customer will buy, and flag any gap in locations, subservice organizations or products. The output is a scope comparison table signed off by the person who owns the service.
Check the customer may receive that report type
Confirm the distribution rules before sending anything. A SOC 2 report is generally restricted to specified users, while a SOC 3 report is a general use report that may be freely distributed, so offering a SOC 3 where the customer needs a SOC 2 is not a substitute. Ask the auditor or the vendor's compliance lead whether a non-disclosure agreement is needed. The step is complete when the distribution path and any NDA are recorded in the proof record.
Map the customer's own controls
List every control the customer must verify themselves, such as configuration of their own tenants, identity provisioning, log retention in their environment, and any responsibilities the report marks as complementary user entity controls. Where a framework relies on the customer's own assessment, such as PCI DSS responsibilities split between a service provider and a merchant, state who performs which step. The output is a responsibility matrix that the customer's own compliance team reviews and accepts.
Record the accepted proof and its limits
Write one closing record that names the proof accepted for each requirement, the issuer, the date of the lookup, the scope, the period, the distribution terms and the open customer-side controls. Include a line stating that a certificate or report does not replace the customer's legal obligations, and that regulators may still find violations. The record is complete when the customer's signatory has acknowledged it in writing, and it is reviewed again when the report or certificate changes.
Which proof fits which buyer situation
A payment processor, merchant or service provider handling cardholder data is validated against PCI DSS, and the proof is documentation on official PCI SSC templates rather than a certificate. Depending on the entity's role and volume, that means a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, each closed with an Attestation of Compliance. PCI SSC states that certificates are not recognized as validation, so a certificate from another body will not satisfy a card brand or acquirer request.
- The AOC is the artifact customers ask for: Buyers and acquirers typically request the current Attestation of Compliance, which shows the assessment type and its outcome.
- Certificates do not count: PCI SSC's FAQ 1220 makes clear that a certificate is not accepted as validation, even from a respected body.
- Assessor reports vary by entity: A ROC requires a QSA, while an SAQ is self-completed, so confirm which the acquirer expects for your merchant or service provider level.
- SOC 2 reuse is limited: A QSA cannot rely on SOC 2 or SOC 3 reports for PCI DSS, but may reuse evidence after independently reviewing it, which can reduce duplicated evidence work.
- Version currency: PCI DSS v4.0.1 is the only active version, so confirm the AOC references it.
Ask your acquirer or payment brand which assessment type, template version and validity date they require before scoping any work.
A US defense supplier handling controlled unclassified information faces CMMC, where the level set by the contract determines the proof. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Level 3 certification assessments are performed by DCMA DIBCAC. The result is a certification outcome from an assessment body, not a self-declaration, so the supplier should confirm the level its contracts require before choosing evidence.
- Level 2 goes to a C3PAO: Third-party certification assessments at this level are performed by authorized or accredited C3PAOs under 32 CFR Part 170.
- Level 3 goes to DCMA DIBCAC: Government assessment applies at this level, so the supplier should not plan for a private assessor to issue it.
- Accreditation body matters: Confirm that a C3PAO is authorized or accredited by The Cyber AB before contracting.
- Scope drives cost and effort: The boundary of systems handling CUI determines how much evidence the assessor reviews, so define it early.
- Recheck the rule text: The regulation in 32 CFR Part 170 sets the assessment rules, so confirm current requirements with the contracting officer and the regulation itself.
Confirm the required CMMC level and assessment type in the contract clauses before selecting a C3PAO or preparing evidence.
A business associate serving US covered entities should expect the question, 'are you HIPAA certified?' and answer it carefully. There is no HIPAA certificate. HHS states that no Security Rule standard requires an entity to certify compliance, that it does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation. Customers therefore ask for evidence of controls, not a certificate, and the business associate must supply that evidence itself.
- No HIPAA certificate exists: Any vendor offering one is describing a private certification that HHS does not recognize.
- Private certifications are not a shield: HHS notes they do not relieve covered entities of their legal obligations.
- Evidence is the deliverable: Typical artifacts include a risk analysis, policies, control descriptions and, where a customer requires it, an independent report such as a SOC 2 or a HITRUST assessment.
- Match the report to the question: A SOC 2 Type 2 shows operating effectiveness over a period, while a Type 1 shows design as of a date.
- Contract terms carry the obligation: Business associate agreements define what you must do, so review them alongside any assurance report.
Ask each customer which evidence their risk team actually reviews, and confirm the wording of any assurance report before presenting it as proof of HIPAA compliance.
An EU entity under NIS2 or DORA has no certificate to show. Under NIS2, national competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. DORA follows the same supervisory logic, with competent authorities using the powers in Article 50. The only authority-issued attestation DORA provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7). The proof is therefore a file of evidence ready for a regulator, not a document a customer can download.
- Supervision replaces certification: Authorities examine your controls directly, so the record must stand up to inspection.
- Only one DORA attestation: The Article 26(7) attestation concerns threat-led penetration testing, not overall DORA compliance.
- Customers ask for different evidence: Financial and critical customers typically request security assurance, contract terms and incident procedures, which you must provide yourself.
- Certification-like schemes may still help: An ISO 27001 certificate or SOC 2 report can support customer questions, but it does not discharge NIS2 or DORA duties.
- Map before claiming: ENISA states its mappings are not a measure of equivalence, so do not present a mapping as proof of regulatory coverage.
Confirm with your national competent authority or financial supervisor what evidence they expect and how they will examine it.
Questions buyers ask before hiring outside help
Is an ISO 27001 certificate always better than a SOC 2 report?
No. The two produce different proof for different readers. An ISO/IEC 27001 certificate is issued by an accredited certification body after it audits an information security management system against the standard, and it is a point-in-time certificate on a three-year cycle. A SOC 2 report is written by a CPA firm under AT-C section 205 and describes controls for the services you select. A Type 1 report covers control design as of a date, and a Type 2 report adds an opinion on operating effectiveness over a period. Many US enterprise buyers ask for a SOC 2 Type 2 report, while many European and global buyers ask for an ISO certificate. Ask your largest customers which proof they request before choosing. Some teams pursue both, and much of the evidence overlaps.
What drives the cost of ISO 27001 or SOC 2 readiness?
Three things determine most of the effort: scope, the number of systems inside it, and how evidence is collected. A narrow scope covering one product and its supporting cloud accounts is far cheaper to prepare for than an entire company with many business units. Each additional system adds access reviews, change records, backup tests and logging to collect. Evidence collection is often the largest recurring workload, especially if controls are run manually. The auditor's fee is paid by you directly to the certification body or CPA firm, and it depends on scope and sampling, so get it in writing from each auditor. Readiness support, gap assessment and remediation are separate costs. Ask any provider for a fixed-scope quote that lists the systems, control set, deliverables and what you must supply.
How long does ISO 27001 or SOC 2 work take?
It depends on the report type and on how ready your controls already are. A SOC 2 Type 1 report needs the system description and control design in place as of one date, so preparation is usually shorter. A Type 2 report needs controls to operate over an observation period, which means evidence must be produced consistently throughout that window before the auditor tests it. For ISO/IEC 27001, the certificate lasts three years under the certification cycle in ISO/IEC 17021-1, with at least one audit in every calendar year, either surveillance or recertification. Certificates issued to the 2013 edition had to expire or be withdrawn by 31 October 2025 under IAF MD 26:2023, so new work targets the 2022 edition. Confirm timelines with each auditor and with your own change calendar, because no universal duration applies.
Can our own team prepare the evidence for an audit?
Often yes, for a well-defined scope with an engineering team that already runs change management, access reviews and logging. The work is mostly disciplined collection: policies, asset inventories, risk registers, access review records, vulnerability reports, training records and vendor reviews, each tied to a control. Problems usually appear in consistency rather than content. Evidence gathered once for a single audit date is not enough for a Type 2 period or a three-year ISO cycle, so you need a recurring owner for each control. A readiness review by someone who has not built the controls often finds gaps your team cannot see. Ask the auditor which evidence formats they accept before collection begins, so your team does not rebuild it later.
What do our internal staff need to commit to the work?
Three roles matter most: an executive sponsor who owns the scope decisions, a control owner for each area such as access, change, backup and vendor management, and an engineer who can pull system evidence on demand. Expect ongoing time from identity, cloud, endpoint and HR teams, and expect the workload to peak around the audit window and recur after each one. The people who run the controls should also be the people who produce the evidence, which keeps records accurate. Ask any outside partner which tasks they will do and which require your staff, and get that split written into the scope.
What does a fixed-scope engagement with DeployOpen define?
DeployOpen's engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For compliance readiness, that document should name the framework or Trust Services categories in scope, the systems and environments covered, the controls to be documented or tested, the evidence artifacts to be produced, and what your team must provide. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports, attestations or certifications. An independent auditor or certification body performs that work and charges you directly. Ongoing support, upgrades and continuous testing are available as separate retainers. Price is set by the written scope, so request a quote that lists each deliverable and each assumption.
Where official mappings help and where they do not prove equivalence
Official mappings show where two frameworks overlap, but they do not transfer proof from one to the other. The CIS Controls Navigator for v8.1 maps the CIS Controls to 30 frameworks and versions, NIST publishes informative references between the CSF 2.0 subcategories and standards such as ISO/IEC 27001:2022 and PCI DSS, and HITRUST describes its CSF as harmonizing more than 70 authoritative sources. These are useful for planning a shared control set. They are not conformity assessments. NIST states that it does not check the correctness of non-NIST mappings and that listing a mapping does not imply endorsement. ENISA is more explicit still: its NIS2 mapping is not a measure of equivalence and does not assess whether a standard fully covers the regulation's requirements.
The practical consequence is that a shared control does not carry a certificate or attestation across frameworks. If your ISO/IEC 27001 certification body samples access reviews, that result does not become a SOC 2 Type 2 opinion, a PCI DSS Attestation of Compliance, or evidence of NIS2 compliance. Each proof is issued by a different party under different rules, and the reader of each proof will check what it covers. Before you tell a customer or regulator that one control satisfies another regime, confirm the mapping row in the source document, the scope of the assessor's report, and whether the other party accepts the claim.
PCI SSC FAQ 1567 is the one case where reuse is explicitly allowed. A QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment, but may reuse the underlying evidence after independently reviewing it. Plan for that review as real assessor work, not a formality: ask your QSA early which SOC 2 evidence they will accept, confirm the SOC 2 period covers the PCI assessment window, and keep the access, logging and change records organized by control so the reviewer can trace each one. Reuse can reduce duplicated evidence collection, but it does not replace the PCI DSS report on compliance.
How DeployOpen helps teams prepare evidence for the right proof
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares the systems, controls and evidence that a compliance assessment will examine. We do not issue audit reports, attestations or certifications; independent auditors, certification bodies and assessors do that work.
How we scope
- Engagements are fixed-scope, with the frameworks, systems and proof types agreed in writing before work starts.
- The written scope states which proof you are preparing for, such as a certification, a CPA attestation report or an assessor report.
- Scope names the systems, environments and data in boundary, so the evidence matches what the auditor or assessor will test.
How we build
- We configure the self-hosted platform and its controls so each requirement maps to a named, testable control.
- We build evidence collection (configurations, access records, change logs and policy records) around the control owners you name.
- We run security testing where the scope calls for it, so the evidence reflects tested controls rather than documented intent.
How we hand over
- Deliverables include control documentation, system descriptions and an evidence index organized by framework requirement.
- We document which evidence supports a point-in-time design review and which supports testing of operation over a period.
- Handover lists open gaps and the items your independent auditor or assessor will need to confirm directly with you.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement ends.
- A retainer can keep evidence current between assessment cycles, including updates after platform upgrades or scope changes.
- Before any quote, we ask you to confirm which assessor, certification body or regulator will review the evidence, since their requirements set the final proof.
Sources and further reading
- ISO: Certification ↗
- AICPA SOC 2: SOC for Service Organizations, Trust Services Criteria ↗
- PCI SSC FAQ 1220: compliance certificates ↗
- CMMC Program final rule, 32 CFR Part 170 ↗
- HHS FAQ 2003: Are we required to certify our organization's compliance with the standards? ↗
- Directive (EU) 2022/2555 (NIS2), EUR-Lex ↗
