Which SOC 2 evidence a self-hosted Dify can produce for AI workloads
A SaaS company that runs Dify for customer-facing or internal AI features needs to know, before the audit starts, which of its SOC 2 evidence Dify can produce and which must come from elsewhere. The 2017 Trust Services Criteria apply the common criteria CC1 to CC9 to every SOC 2, so the security category is always in scope. Dify supplies useful material for some of those criteria, mainly the logical access series (CC6) and change management (CC8), but it does not satisfy them on its own. The organization's governance, risk, HR and incident processes sit outside the platform. Auditors and licensed CPAs issue the report. DeployOpen plans, configures and documents the system and prepares the evidence, but it does not certify or attest to anything.
For access, the evidence starts with Dify's workspace roles and, on the Enterprise edition, SSO. The SSO documentation lists OpenID Connect, SAML and OAuth2 with identity providers such as Microsoft Entra ID and Okta, and separate scopes for workspace access and web app access. The Community edition is limited to a single workspace and does not include SSO, so an organization that needs centrally managed access reviews should confirm early whether Enterprise is required. Change history comes from app versions and DSL exports, which capture workflow nodes, prompts and model parameters but not third-party API keys, knowledge base content or usage logs. Those excluded items need their own records. Backups, log retention and model provider records also need separate procedures. Confirm with your auditor which populations and time periods they will sample.
Dify's own deployment settings also matter for the evidence. Upgrades follow the guide for each target version, and the Dify releases page shows minor releases arriving roughly monthly, so the change log for the platform itself must be kept. Dify's documentation recommends a backup before every upgrade, and that backup record becomes evidence for the change and availability criteria. Before the first audit window, confirm with the auditor how the system description, the boundary and the vendor relationships with model providers will be documented. The 2018 description criteria govern that description. A Type 1 report tests design at a point in time, while a Type 2 report tests operating effectiveness over a period, so the evidence should be collected continuously rather than assembled at the end.
Mapping SOC 2 criteria to Dify capabilities and configuration
This table maps the SOC 2 common criteria and the availability and confidentiality categories to what a self-hosted Dify provides, the configuration each control needs, and what stays with your organization. Read each row as a question the auditor will ask, then check whether the Dify capability and your settings produce evidence for it. Most gaps sit in the customer controls column, especially review cadence and retention.
| Criterion and requirement | Dify capability and source | Configuration needed | Remains a customer control |
|---|---|---|---|
| CC6: Logical access is restricted and reviewed | Workspace roles and SSO scopes for workspace access and web app access; Enterprise SSO supports OpenID Connect, SAML and OAuth2 (Dify Enterprise SSO docs) | Set workspace roles deliberately, enable SSO on Enterprise, and separate workspace access from web app access | Quarterly or periodic access reviews, joiner and leaver process, and exported role assignments kept as evidence |
| CC6: Secrets and session integrity | SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials; workspace encryption keys can be stored locally or in Azure Key Vault (Dify environment reference) | Generate a unique SECRET_KEY, store it in your secrets manager, and choose the key storage location before go-live | Key rotation schedule; note that changing SECRET_KEY logs out all users, so plan the change window |
| CC6: Outbound access and internal network protection | SSRF_PROXY routes outbound requests through a proxy that blocks internal and private IP ranges (Dify environment reference); 1.16.1 added agent sandbox network isolation through a Squid proxy (Dify 1.16.1 release notes) | Keep the SSRF proxy enabled, confirm sandbox network isolation on your deployed version, and restrict egress at the network layer | Firewall rules, allowlists for approved model endpoints, and testing that the controls behave as configured |
| CC7: System operations and logging | Logs and app-level monitoring through LLMOps features; Enterprise audit log records operations (Dify Enterprise audit documentation covered in sibling topic) | Route container and application logs to your central store, set retention for each log source, and confirm which operations the edition records | Log retention period, SIEM ingestion, alerting on access and configuration changes, and review of log samples |
| CC8: Change management of apps and platform | Apps export and import as YAML DSL files, including prompts, workflow nodes and model parameters but not API keys, knowledge base content or usage logs (Dify app management docs); upgrades should be preceded by a backup (Dify Docker Compose docs) | Store exported DSL in version control, record the Dify version in each change, and follow the upgrade guide for each target release | Approval workflow for app changes, upgrade testing, and records of who approved each release |
| CC9: Risk and vendor management | Dify pricing lists Enterprise as the edition with a commercial license and professional support (Dify pricing page); the Dify license restricts multi-tenant operation without written authorization (Dify LICENSE) | Record the Dify edition and license terms, and keep model provider contracts and data processing terms on file | Vendor risk assessments for each model provider, review of Dify release notes, and the risk register entry for the platform |
| A1: Availability and backups (where in scope) | Dify Enterprise can be deployed on Kubernetes for high availability (Dify deployment overview); Community runs anywhere Docker runs (Dify deployment overview) | Plan backups of PostgreSQL, vector store and file storage, and test restores; the metadata database and file storage can be external services | Restore tests with recorded results, recovery time objectives you set, and capacity planning |
| C1: Confidentiality of stored data (where in scope) | File storage can use S3-compatible or other object storage; vector store options include Qdrant, Milvus, pgvector and others (Dify environment reference) | Choose storage locations inside approved regions and enable encryption at rest in each backing service | Data classification, retention and disposal of knowledge base content, and access controls on backing stores |
Community or Enterprise: which edition changes the evidence you can show
The Community edition is free to self-host and, according to the Dify pricing page, is limited to a single workspace. For SOC 2 purposes, that means every application, knowledge base, member and setting sits inside one boundary. An auditor's access review sample then covers the whole deployment, which keeps the system description short but leaves every team sharing the same administrative scope.
- One workspace boundary: all applications, datasets and members share one scope, so the access review covers everything in a single list.
- Shared administrator roles: separating duties between platform and application owners depends on how you assign roles inside that one workspace.
- Login options: the pricing page lists SSO under Enterprise, so plan how Community users sign in and how their access is removed when they leave.
- Self-managed records: deployment, upgrade and backup records come from your own infrastructure and tooling, not from the platform.
Check the current Community feature list on the Dify pricing page before you write the system description.
The Enterprise edition adds multiple workspaces, which lets you draw a scope boundary around a group of applications, members and knowledge bases. For SOC 2 evidence, that boundary gives the auditor a smaller population to sample, and your access reviews can be certified per boundary instead of across one long member list.
- Scoped access reviews: reviewers certify members workspace by workspace, which makes each review easier to complete and to evidence.
- Environment separation: keeping staging and production in different workspaces isolates the change records for production.
- Named ownership: each workspace can have an accountable owner who signs the review for that scope.
- Illustrative example: a SaaS company might keep a customer-facing support assistant in a production workspace and prototypes in another, so the production change sample stays focused on live systems.
Confirm with Dify how workspaces are provisioned, whether administrator rights span more than one workspace, and how membership changes are recorded.
The Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID, Okta and GitHub. It also separates SSO scopes for workspace access and web app access. This moves much of the access evidence to your identity provider, where group membership and account removal are already recorded.
- Supported protocols: OpenID Connect, SAML and OAuth2 are named in the Enterprise SSO documentation, so match them to your provider's configuration.
- Workspace access scope: governs who can enter the Dify console and therefore who can change apps and settings.
- Web app access scope: governs who can use a published app, which matters when end users of your product reach an assistant.
- Provider as record: the provider's group exports and deprovisioning logs become sampled evidence for joiner, mover and leaver tests.
- Propagation gap: confirm whether group mapping is supported for your provider and how quickly a removed account loses Dify sessions.
Test a revoked user in a non-production workspace and keep the dated result as evidence.
Auditors test whether changes are recorded, who made them and whether the records can be produced on request. The facts available for this page do not establish which Dify edition includes an audit log, what it captures, how long entries stay queryable or how exports are formatted. Confirm those points directly with Dify before you depend on them in a control description.
- Administrative actions: confirm whether changes to members, roles, applications and permissions are logged in your version.
- In-platform retention: check how long records remain queryable and whether an external store is needed to keep them for your review period.
- Export format: confirm whether exports exist, which fields they contain and whether they can be handed to an auditor unchanged.
- Log forwarding: plan a destination you control, so records survive any platform retention window or a rebuild of the deployment.
- Actor and time fields: verify each entry records the acting user and a timestamp, since auditors test both during a sample.
Ask Dify to demonstrate an export against a test workspace before you choose an edition.
Edition feature lists, pricing and support terms change over time, and documentation can lag behind a release. The Enterprise edition is custom priced, so the cost depends on the written scope and the commercial terms you agree. Treat the difference between editions as a claim you verify in writing, not as a settled fact in your audit plan.
- Feature matrix in writing: request written confirmation of SSO, workspace, audit log and export capability for the exact version you will run.
- Commercial terms: the pricing page describes Enterprise as custom priced, so ask what the license, professional support and any upgrade assistance cover.
- Version alignment: Dify releases arrive roughly monthly according to the releases page, so a feature may differ between the version you test and the one you deploy.
- Your own controls: Enterprise features support evidence but do not replace your access reviews, change approvals and backup tests.
Attach the dated, confirmed feature list to your system description so the auditor can see which edition and version the evidence came from.
Evidence to export and retain for the SOC 2 examination period
A SOC 2 Type 2 auditor samples evidence from the whole examination period, not just the day of the audit. Each card below names one artifact a self-hosted Dify deployment must produce, who produces it, and how often it must be captured so the operating effectiveness of your controls can be shown.
Access review exports
Export workspace member roles and, where SSO is used, the identity provider groups mapped to them, then compare both against the access list approved by the control owner. Auditors typically sample a quarterly review, so capture a dated export each review cycle and record who removed stale accounts. Confirm whether your Dify edition supports SSO and role exports before you promise a specific review method. Capture each review cycle, with the approver's sign-off attached.
Audit log exports and retention
Audit logs show who changed apps, models, and access settings. Decide where they live, how long they are kept, and who can export them, then export on a fixed schedule into storage your security team controls. Check the Enterprise audit log window and export options with the vendor, because online query limits can be shorter than your examination period. Sample a few logged changes against tickets to show the log is complete.
App version and DSL change records
Dify apps can be exported as YAML DSL files, and those exports capture app configuration, workflow nodes, model parameters and prompts. Store a dated DSL export for each production app whenever it changes, with the change ticket and reviewer linked. Exports do not include third-party API keys, knowledge base content or usage logs, so those need separate records. This set of files becomes your change history for the period.
Backup and restore test records
Auditors look for proof that backups run and that restores work. Keep backup job logs for the PostgreSQL metadata database and the object storage that holds uploaded files, plus the secret material needed to decrypt them. Record a restore test at a planned interval, noting the date, the operator, the target environment and the result. The Docker Compose upgrade guidance recommends a backup before every upgrade, so keep those pre-upgrade backups as evidence too.
Logging retention and cleanup settings
Record the retention values your deployment actually uses, not the defaults you assume. Dify includes a cleanup default for old conversation and workflow data, so set it deliberately, document the value in your configuration baseline, and capture a copy of the environment file at each review. Show who approved any change to retention and when it took effect. Confirm with the vendor how cleanup jobs are logged, since the job record is itself evidence.
Model provider and vendor records
List every model provider, self-hosted model endpoint and embedding service the apps call, with the contract or terms in force, the data processing commitments and the named internal owner of each API key. Rotate keys on a schedule and keep rotation tickets. Reconcile this register against the provider entries configured in Dify each quarter, because a key added in the console without a register entry is a common finding.
How app versions, upgrades and releases become change management evidence
Change management evidence for a self-hosted Dify comes from linking four records into one trail: the change ticket, the staging test, the configuration state before and after, and the release notes for the version you moved to. Dify minor releases arrive roughly monthly. The supplied release dates show 1.16.0 on July 17, 2026, 1.17.0 on August 25, 2026 and 1.17.1 on September 10, 2026. Your auditor will not expect you to stop upgrading, but will expect each upgrade to follow a documented, repeatable path. Decide who approves a version change, and how often you review the Dify releases on GitHub page for security-relevant notes.
Each upgrade should start from the target version's upgrade guide, which the Docker Compose docs direct you to on the Releases page. Take a backup before every upgrade, then check .env.example for new variables and compare them with your live .env. Store the diff, the backup reference and the image tags in the change record. For security-relevant releases, such as 1.16.1, which the release notes describe as adding agent sandbox network isolation through a Squid proxy, token-based API authentication between services and sandboxed Jinja2 template rendering, attach the relevant notes to the ticket and record which controls changed. Confirm each claim against the release notes before you cite it.
App-level change history is a separate record. Export each app as a DSL file before and after a change, since the export covers configuration, workflow nodes, model parameters and prompts, but not API keys, knowledge base content or usage logs. Tie each export to the ticket, the staging test result and the approver. Keep the exports in version control so an auditor can compare any two states. Confirm with your auditor whether they want the ticket, the diff, the test evidence or all three sampled together, and agree that format before your observation window opens.
Configuration sequence before the audit period starts
This sequence turns a working self-hosted Dify into a deployment with defined boundaries, controlled secrets, traceable changes and recorded vendor relationships, so the first audit period begins with evidence already being produced.
Define the system boundary and in-scope criteria
Start with a written system description that names the Dify components in scope (api, worker, web, plugin daemon, PostgreSQL, Redis, the vector store, file storage and the sandbox), the workspaces and apps that handle customer data, and the model providers they call. Agree with your auditor which Trust Services Criteria apply, since security (the common criteria) is always included and the other categories are added only when in scope. Done when the boundary document is approved and every component on the list has an owner.
Set SECRET_KEY and encryption key handling
Generate a unique SECRET_KEY for the deployment and store it in your secrets manager, not in a shared .env file. Record who can read it and how it is rotated. Decide where workspace encryption keys live, either local storage or a key vault such as Azure Key Vault where your environment supports it. Note that changing SECRET_KEY after deployment logs out all users, so the rotation procedure must be planned with users in mind. Done when the key source, custodian and rotation steps are written down and the secret is absent from version control.
Route outbound calls through the SSRF proxy
Confirm that outbound requests from Dify, including tool calls, webhooks and model endpoints, pass through the SSRF proxy configured by the SSRF_PROXY settings, which blocks internal and private IP ranges. Check that the agent sandbox network isolation described in the 1.16.1 release notes is active in your version. Test a request to an internal address and confirm it is refused. Keep the test output as evidence for the network and access criteria.
Configure SSO and role mapping
Connect your identity provider and map its groups to Dify roles for workspace access and, separately, web app access. Community edition login options are limited, so confirm with your Dify edition whether SSO is available before you commit to a design. Disable local sign-up for production workspaces. Done when a test user from each group reaches only the workspaces and apps their role allows, and the mapping table is stored with the change record.
Set log and backup retention
Decide retention periods for application logs, conversation records, the PostgreSQL database and file storage, then write them into the environment and the backup schedule. Dify's default cleanup settings may not match the periods your commitments require, so confirm each setting against the environment reference for your version. Confirm that logs are shipped to a store you control, because the audit trail must survive the cleanup jobs. Done when the retention table is approved and a sample log entry can be found after the configured window has been tested.
Establish the change and release procedure
Write a procedure covering how app versions are published, how Dify platform upgrades are tested in a non-production environment, and who approves each change. Use exported DSL files and the app version history as the change record for workflows and prompts. For platform upgrades, follow the upgrade guide for the target version, take a backup before each upgrade, and review .env.example for new variables. Minor releases arrive roughly monthly, so the cadence must be set deliberately. Done when a sample change has passed through the procedure with an approval and a recorded rollback plan.
Collect vendor records for each model provider
For every model provider and embedding or rerank endpoint, record the contracting entity, the data handling terms you accepted, the regions where data is processed, the credential owner and where the API key is stored. Keep this list in your vendor management system and link each provider to the apps that use it. Ask each provider for its own assurance report where one is offered, and file it. Done when every model connection in Dify maps to a vendor record with a named owner.
Run one access review and one restore test
Run a complete access review across Dify workspace roles, web app access, admin accounts and service API keys, then record who approved each entry and what was removed. Separately, restore the PostgreSQL database and file storage from the latest backup into a separate environment and check that apps, knowledge bases and users load correctly. Record the restore time and any gaps. Done when both results are signed off and any findings have tickets with owners.
Begin evidence collection on a fixed schedule
Set a recurring calendar for evidence tasks: access reviews, backup restore tests, change records, vendor reviews and SSO mapping checks. Assign each task to an owner and store the output in one location organized by criterion. A SOC 2 Type 2 report covers operating effectiveness over a period, so the controls must run consistently from the start of that period. Confirm the schedule and evidence format with your auditor before the period opens. Done when the first cycle of evidence is filed against each recurring task.
What the platform does not cover for SOC 2
A self-hosted Dify can produce logs, configuration history and backups, but a SOC 2 examination covers the whole service organization. The cards below are the controls and evidence that sit outside Dify and that an auditor will still test, along with the one input that needs confirmation before you rely on Dify's logs at all.
Policies, risk assessment and training
The organization must write and approve its own security policies, perform a documented risk assessment, and train staff on them. Dify has no role in these documents, but the auditor will compare them against what the Dify deployment actually does. A policy that requires quarterly access reviews needs a dated review record for the Dify workspaces, and a risk register should name the AI-specific risks such as prompt data leaving the environment through a model provider. Check that each Dify control you describe in the system description appears in a policy someone owns.
Independent testing and the report
The auditor's independent testing, sampling and written opinion are the core of the engagement, and DeployOpen does not issue audit reports, attestations or certifications. A SOC 2 Type 1 report describes control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period. Ask the auditor early which Dify evidence they will sample, in what format, and over what period, so the logging and backup settings are in place before the observation window opens.
Vendor due diligence and model provider contracts
Each model provider, embedding service and plugin source that receives data from Dify is a subservice relationship your auditor will ask about. You need current contracts, security reports where the provider offers them, data processing terms and a list of which providers each app uses. Dify's record of model provider configuration does not replace that vendor file. Confirm how each provider handles retention and training on your data before any app goes to production.
Personnel and physical controls
Background checks, onboarding and offboarding, device management, and the physical security of the data center or cloud account hosting Dify all sit outside the application. Removing a departing engineer from Dify does not revoke their cloud console, database or SSH access, so the offboarding checklist must cover every system that holds the SECRET_KEY, database credentials or object storage keys. Ask your hosting provider for its own SOC 2 report and map its controls to yours.
Monitoring and incident response
Dify's logs cover application activity, but detecting and responding to an incident requires alerts, a central log store, on-call duties and a tested response plan. Forward container, reverse proxy and database logs to a system outside the Dify host so a compromised instance cannot erase them. Define who reviews alerts, how incidents are classified and how you notify customers. The auditor will sample incident tickets and post-incident reviews, so keep them even when no incident occurred.
Logging and retention settings by version
Before you promise an auditor a retention period, confirm what each Dify version writes to its logs, how long conversation and workflow records persist, and which cleanup jobs delete them. Retention behavior and log content can change between releases, and Dify publishes minor releases roughly monthly. Test a restore and an export on your exact version, record the results, and keep that record with your change history. Do not state a retention period in your system description until this check is done.
Auditing standard changes ahead
The AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026. If adopted, they would apply to engagements beginning on or after June 15, 2029, according to the Journal of Accountancy. Your current engagement is governed by the standards in force today, so this affects planning rather than this year's examination. Ask your auditor how they expect to apply any revised standard to your next report and whether management representations will change.
What a SOC 2 evidence project for Dify costs and needs from your team
What drives the effort of a SOC 2 evidence project for Dify?
The main drivers are how many Dify workspaces are in scope, how many SSO integrations and model providers must be documented, which trust services categories beyond security the examination covers, and whether the report is a Type 1 or Type 2. Each workspace adds its own access reviews and app change history. Each model provider adds a vendor record and a data handling position. Availability, processing integrity, confidentiality and privacy each add criteria only when they are in scope. A Type 2 report also requires evidence that controls operated across the examination period, which is more work than a point-in-time Type 1 view. Ask your auditor to confirm the scope before anyone estimates effort.
Can an internal team prepare SOC 2 evidence for Dify on its own?
Yes, a capable internal team can build the evidence, provided it has time, a named owner and the skills to map controls to the 2017 Trust Services Criteria. The work is mostly configuration, export and documentation: role definitions, SSO settings, audit log exports, app version history, backup records, log retention settings and vendor files for each model provider. The harder part is consistency over time, because evidence must be collected on a schedule and reviewed by someone other than its producer. Teams without a SOC 2 background often underestimate the description of the system and the management assertions. A CPA firm must still perform the examination, so your internal team should confirm early what the auditor expects to see.
How does the examination period affect a SOC 2 timeline for Dify?
A Type 1 report describes the system and the design of controls as of one date, so preparation centers on documenting and configuring controls before that date. A Type 2 report covers a period and an auditor tests whether controls operated throughout it, so evidence must exist for every control across the whole window. Access reviews, change records, backup restore tests and log retention must each occur on a repeating schedule. Starting evidence collection late means gaps that cannot be filled retroactively. Your auditor sets the period and the sampling approach, so agree both in writing before the observation window opens. Ask any provider to describe what evidence is collected in the period and who checks it.
What does a SOC 2 evidence project need from identity, platform and compliance staff?
Each function owns different evidence. Identity staff provide the SSO configuration, the identity provider's user lists, group membership and joiner and leaver records that feed Dify access reviews. Platform staff provide the deployment inventory, environment variable settings for secrets, backup jobs and restore test results, upgrade records and network controls. Compliance staff define the control matrix, decide which criteria are in scope, collect vendor agreements and security documents for model providers, and run the review cycle. Expect each group to spend recurring time on evidence, not only on the first build. Agree these responsibilities and a single evidence owner before work begins.
Does DeployOpen or a CPA firm issue the SOC 2 report?
A CPA firm issues the SOC 2 report. DeployOpen plans, implements, documents and hardens the self-hosted Dify environment and prepares the systems, controls and evidence that an auditor will examine. DeployOpen does not issue audit reports, attestations or certifications. The auditor makes its own tests, selects its own samples and forms its own opinion, which is why scope and evidence formats should be agreed with the auditor early. Keep the auditor and the implementation partner in the same planning conversation so that evidence is produced in a form the examination can accept.
How do Dify Community and Enterprise editions change SOC 2 scope?
The pricing page lists the self-hosted Community edition as free and limited to a single workspace, while the self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Those differences change the evidence. With Community, the number of workspaces is limited, and SSO options and audit logs may need to be built differently, so confirm what each edition provides for access reviews and logging before choosing. With Enterprise, the price is set by quote, so the licensing cost enters the written scope as a separate line. Confirm current features with Dify directly, since editions and their contents can change.
What should a written quote for a SOC 2 evidence project include?
A written quote should list the scope in full. Ask for the trust services categories included, the number of Dify workspaces, SSO integrations, model providers and environments covered, and whether the report is Type 1 or Type 2. It should name each deliverable, such as the control matrix, system description inputs, evidence runbooks, access review procedure and backup restore evidence. Ask which tasks are one-time, such as initial configuration, and which recur, such as periodic access reviews and log exports. Confirm what the client provides, the assumptions about the auditor and the change process if scope grows. Also confirm which licenses, infrastructure and third-party fees sit outside the quote.
How DeployOpen scopes, configures and documents SOC 2 evidence for Dify
DeployOpen plans, implements, hardens and documents self-hosted Dify inside your own infrastructure, so the access, change, backup and logging records an auditor samples are built in from the start. We prepare systems, controls and evidence for a SOC 2 examination, but independent auditors issue the report.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which Trust Services Criteria apply to your Dify system boundary, including whether privacy or confidentiality are in scope.
- We inventory every Dify workspace, app, knowledge base, model provider and hosting location that falls inside the system description.
How we build
- We configure SSO and role assignments so workspace access can be reviewed from a single, exportable source of truth.
- We set up backups, log retention and the controls around the SECRET_KEY and encryption keys, then test that restores actually work.
- We define a change process for Dify upgrades and app versions, with pre-upgrade backups and recorded approvals kept as evidence.
How we hand over
- We document the system description, control owners, procedures and the evidence location for each control, mapped to the criteria in scope.
- We deliver a vendor record for each model provider and hosting dependency, with the contract and data handling details your team confirms.
- We walk your team through how to pull access reviews, change history and log exports during a fieldwork period.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so controls keep working between audit periods.
- We help your team respond to auditor requests and update evidence when Dify releases or your model providers change.
- Your auditor remains responsible for the examination and the report, and we confirm the points they need clarified during the engagement.
