LLM Security Certifications, in depth: certificates versus attestations, scoping the model path, one control set for many reports, and a sequencing plan

Certificate, attestation, assessment, law

Certification. An accredited certification body audits your management system against a standard and issues a certificate. ISO/IEC 27001 (information security) and ISO/IEC 42001 (AI management systems, published in December 2023) work this way. The audit follows ISO/IEC 17021-1: a stage 1 review of documentation and readiness, a stage 2 audit of whether the system actually operates, then a three-year cycle with surveillance audits in the intervening years and a recertification audit at the end. For 42001, ISO/IEC 42006:2025 adds requirements on the certification bodies themselves, including auditor competence in AI, so ask whether your body is accredited for 42001 and by whom.

Attestation. SOC 2 is not a certification. A CPA firm examines a description of your system and your controls against the AICPA Trust Services Criteria and gives an opinion. A Type 1 report covers design at a point in time; a Type 2 report covers design and operating effectiveness over a period, commonly six to twelve months. The report is restricted-use and shared under NDA; SOC 3 is the short general-use version. Saying you are 'SOC 2 certified' is a small error that experienced reviewers notice.

Assessment programs. HITRUST offers an AI security assessment with certification (general availability announced in November 2024) that layers AI-specific controls on its framework. The Cloud Security Alliance publishes the AI Controls Matrix, whose version 1.1 lists 247 control objectives across 18 domains, and has announced a STAR for AI program; check its current status before promising it to a customer.

Frameworks with no certificate. The NIST AI Risk Management Framework is voluntary guidance; nobody issues a NIST AI RMF certificate, and anyone selling one is selling their own opinion. The EU AI Act is law: providers of high-risk systems perform a conformity assessment, which for most Annex III use cases is internal control by the provider. An ISO/IEC 42001 certificate is useful evidence for that work but is not itself conformity with the Act.

Which document answers which question

Read the right column aloud in sales calls. Customers who have been burned before ask exactly these follow-ups, and an answer that admits the limit earns more trust than a logo wall.

Architecture: one control set

The architecture that keeps certification affordable is boring: evidence comes from systems you run anyway, every control has one owner and one identifier, and a crosswalk maps that identifier to the clauses, Annex A controls and criteria of each framework. The opposite pattern, a separate spreadsheet and evidence folder per framework, doubles the work every time you add a report and produces contradictions between them that auditors will find.

Scoping an LLM system

Scope is where LLM products most often get a certificate that does not cover what the buyer cares about. Write the boundary in terms of the request path, not the org chart.

• Model provider. If you call a hosted model, the provider is a subservice organization in SOC 2 terms. Most reports use the carve-out method: the provider's controls are excluded, your report lists the controls you expect them to have (complementary subservice organization controls), and you show that you review their own reports each year. Do the same in ISO terms through supplier controls.
• Retrieval and data stores. Vector indexes, document connectors and caches hold customer data. They must be in scope, including deletion and tenant isolation, or the certificate covers the front door but not the warehouse.
• Agent tools. Every tool that writes, sends or pays is a change to customer systems. Include tool permission reviews and approval logs in access-control evidence.
• Training and fine-tuning. If customer data can reach training, the data-use policy, opt-out handling and dataset lineage belong in scope. If it cannot, say so in the system description.
• Customer responsibilities. List what the customer must do, such as configuring SSO or reviewing agent approvals. SOC 2 calls these complementary user entity controls; buyers read them closely.

For ISO/IEC 42001, two artefacts carry the scope: the Statement of Applicability, which states for each Annex A control whether it applies and why, and the AI system impact assessment that the standard requires for systems in scope. Auditors will pick one of your AI systems and trace it through both.

The crosswalk as code

Keep the crosswalk in version control as data, and generate both gap reports and evidence requests from it. The control identifiers below are yours; framework references are written as labels you fill in from the licensed text of each standard rather than copied from memory.

# controls.yaml -- one entry per control, one owner, many mappings
- id: AI-CHG-01
  title: Model and prompt changes pass the evaluation gate before release
  owner: ml-platform
  evidence: [eval_gate_runs, release_approvals]
  maps:
    soc2: [CC8.1]
    iso27001: [change management]
    iso42001: [AI system life cycle]
- id: AI-SUP-02
  title: Model provider assurance reports reviewed yearly
  owner: vendor-risk
  evidence: [provider_reviews]
  maps:
    soc2: [CC9.2]
    iso27001: [supplier relationships]
    iso42001: [third-party and customer relationships]

import datetime as dt
import yaml

def load(path="controls.yaml"):
    with open(path, encoding="utf-8") as f:
        return yaml.safe_load(f)

def coverage(controls, framework):
    """Which framework references have at least one control mapped to them."""
    hit = {}
    for ctl in controls:
        for ref in ctl.get("maps", {}).get(framework, []):
            hit.setdefault(ref, []).append(ctl["id"])
    return hit

def stale_evidence(controls, store, max_age_days=31):
    """Controls whose newest evidence item is older than the window (or missing)."""
    now = dt.datetime.now(dt.timezone.utc)
    late = []
    for ctl in controls:
        for kind in ctl["evidence"]:
            newest = store.latest(kind)          # your evidence store API
            if newest is None or (now - newest).days > max_age_days:
                late.append((ctl["id"], kind, newest))
    return late

Run stale_evidence weekly in CI and page the control owner, not the compliance team. The point of a Type 2 period or a surveillance audit is that controls operate every week, and the cheapest time to discover a gap is the week it opens. The mechanics of turning these stores into auditor samples are covered in LLM audit preparation.

Worked example: a first report for a bank customer

Take a twelve-person company selling a retrieval assistant to banks. It calls a hosted model, stores customer documents in a vector index, and has one agent tool that files tickets. A bank's procurement team requires a SOC 2 Type 2 report and asks about AI governance. A plan that works:

1. Months 0 to 2. Write the system description and the control set, with the request path as the boundary. Turn on evidence collection: eval gate records, access reviews, provider report reviews, deletion logs. Answer the bank's questionnaire from the control set and say a report is in progress.
2. Month 3. SOC 2 Type 1. It proves design only, but it tells you which controls the auditor cannot test as written, before the period that matters starts.
3. Months 3 to 9. The Type 2 observation period. Fix exceptions as they appear; an exception you found and corrected reads far better than one the auditor found.
4. Months 6 to 12. Add the ISO/IEC 42001 artefacts on top of the same controls: AI policy, risk and impact assessments, Statement of Applicability. Decide on certification only if customers or regulators in your market ask for it.
5. Every year after. Re-read the model provider's reports, re-run the impact assessment when the model or use case changes, and keep the Type 2 periods back to back so there is never a gap.

The order matters. SOC 2 first because it is what this buyer asked for; 42001 second because it reuses most of the evidence and adds the AI-specific governance the bank will ask about at renewal.

What certificates do not prove

Certificates prove that a management system exists and that sampled controls worked. They do not prove that the model resists prompt injection, that retrieval never crosses tenants, or that outputs are accurate. An auditor checks that you run an evaluation gate; they do not re-run your red team. Buyers with serious exposure will ask for test summaries alongside the report, and you should offer them. The re-performance approach in AI compliance audits shows what a deeper reviewer will try.

People credentials are a separate market. Programs such as the IAPP's AI governance professional certification or ISACA's AI security management credential certify individuals, not your system. They can help staff a governance function but satisfy no customer asking about your product's controls.

Failure modes

• Scope that skips the model path. The certificate covers the web app and the corporate network, while the vector index and fine-tuning jobs sit outside. The buyer reads the scope and stops trusting the rest.
• Carve-out with no review. The provider is carved out, but nobody can show the annual review of the provider's report or the bridge letter covering the gap between periods.
• Evals as screenshots. Evaluation evidence lives in slide decks. The auditor asks for the population of releases and the gate result for each; there is no system of record.
• Statement of Applicability by copy. Every Annex A control marked applicable with the same boilerplate justification. Auditors sample the justifications and find they do not describe your system.
• Gaps between periods. A Type 2 period ends in March and the next starts in July. Buyers see four unaudited months and ask why.
• Marketing drift. The website says 'certified' for an attestation, or lists a framework that issues no certificate. Fix the wording before a buyer's lawyer does.

Trade-offs

What to do next

1. List the questions your last ten buyer questionnaires asked and map each to the table above.
2. Draw the request path of your LLM product and mark the scope boundary on it, including model provider, retrieval stores and agent tools.
3. Create a version-controlled control set with one owner per control and a crosswalk to each framework you need.
4. Wire evidence collection to systems of record (eval gate, IdP, KMS, ticketing) and run a weekly staleness check.
5. Choose your first report from buyer demand, then schedule the next periods back to back.
6. Keep learning: structuring an AI governance program and tamper-evident audit logging for LLMs.