When self-managed GitLab or GitLab.com fits your team
Choose self-managed GitLab when hosting location, operational control or offline operation matter to your organization, and choose GitLab.com when a vendor should run the service and hosting in the United States is acceptable. GitLab.com is currently hosted on Google Cloud Platform in the USA, according to the GitLab pricing page FAQ, so teams with data residency rules, air-gapped networks or a requirement to keep source code and CI logs inside their own accounts or data centers should start with self-managed. GitLab documents running self-managed instances in offline environments, which GitLab.com cannot offer.
The choice shapes your subscription, not just your servers. GitLab's subscription documentation says a GitLab.com subscription applies to a top-level group namespace, while a Self-Managed subscription covers every user on the instance with the same feature set. Subscriptions cannot be moved between the two models, so switching later means buying a new subscription. Before you commit, confirm with GitLab which tier and seat count you need for each model, and ask how existing paid seats, compute minutes and storage would be handled if your hosting requirements change.
Decide the hosting model before you adopt paid tiers, CI runners or large repositories, because those are the parts that are hardest to unwind. Ask who will perform upgrades: self-managed teams must follow GitLab's required upgrade stops, documented in the GitLab upgrade paths documentation, and must plan backups and restores themselves. GitLab.com moves that work to GitLab, but you give up control over the upgrade window and the hosting location. Write these responsibilities down in your scope before you pick a model.
Self-managed vs GitLab.com side by side
This table sets the hosted GitLab.com service against a GitLab Self-Managed installation on the attributes that most often decide the choice. Read each row as a question to answer for your own organization, and treat any cell marked for confirmation as an item to raise with GitLab before you sign.
| Attribute | GitLab.com (SaaS) | GitLab Self-Managed |
|---|---|---|
| Where it runs | Hosted by GitLab on Google Cloud Platform in the USA | Installed and maintained on infrastructure you choose, including your own cloud accounts, data centers or air-gapped networks |
| Feature set by plan | Free, Premium and Ultimate, applied per top-level group namespace | Every user on the instance receives the same feature set for the subscription purchased |
| Free tier user limit | 5 users per top-level group | No 5-user cap is listed for the Free tier on Self-Managed; confirm current terms with GitLab |
| Free tier compute minutes | 400 compute minutes per month; jobs on your own runners do not consume them | Not applicable; CI capacity is set by the runners and hardware you operate |
| Free tier storage | 10 GiB of Git repository and LFS storage per project | Governed by your own disks and object storage; confirm any instance-level limits with GitLab |
| Paid tiers and published prices | Premium at 29 US dollars per user per month billed annually; Ultimate is custom priced | All three tiers are available for self-managed installations at the same published prices; confirm quote terms for your user count |
| Repository storage on paid tiers | Fixed limit of 500 GiB per project on Premium and Ultimate | No per-project cap is documented here; confirm with GitLab and size against your own storage |
| Extra capacity purchases | Extra compute minutes at 10 US dollars per 1,000 minutes; extra storage at 5 US dollars per month per 10 GiB, billed annually | Extra capacity is handled through your own hardware and storage budget, not through GitLab.com add-ons |
| Air-gapped or offline use | Not available; the service is hosted and reached over the internet | Documented for offline, air-gapped environments, including guidance for security scanners; confirm your exact tier and features |
| Subscription portability | Cannot move to Self-Managed without buying a new subscription | Cannot move to GitLab.com without buying a new subscription |
Which model fits which team situation
Teams under data residency or sovereignty rules usually start by asking where source code, CI logs and issue data may be stored. GitLab.com is currently hosted on the Google Cloud Platform in the USA, according to the GitLab pricing page FAQ, so a team bound to a non-US location or to a specific jurisdiction will often lean toward self-managed. A self-managed instance lets the team choose the region, the cloud account or the data center, and keep encryption keys and backups inside that boundary. The answer flips when the residency rule accepts US hosting under documented contractual and security terms, and the team would rather hand off upgrades and operations.
- Hosting location: GitLab.com runs in the USA today, while Self-Managed runs wherever the team installs it.
- Key and backup control: Self-managed teams hold the backup files and database, which simplifies showing where regulated data sits.
- Subscription scope: A GitLab.com subscription applies to a top-level group, and subscriptions cannot be moved between GitLab.com and Self-Managed.
- Operating responsibility: Self-managed places upgrade, backup and restore duties on the team or its implementation partner.
- Vendor terms: Contract clauses on sub-processors and data location may matter more than the hosting footprint alone.
Confirm with your compliance lead whether US hosting satisfies the residency rule, what GitLab's current data processing terms say, and whether the auditor expects evidence of backup location and key custody.
Networks with no internet route, such as classified enclaves, industrial control zones and some public sector environments, cannot use a SaaS service at all. GitLab documents running self-managed instances in offline, air-gapped environments, and separate guidance covers the GitLab security scanners and GitLab Duo Self-Hosted offline. This makes self-managed the only realistic path for these teams, so the question becomes how much offline operation the chosen tier and features support. The answer does not flip for these teams, but the operating plan must absorb the work that a hosted service would otherwise do.
- Offline installs: GitLab's offline environments guidance applies to self-managed installs only.
- Scanner content: Security scanners and advisory data need a separate offline update path that the team must schedule.
- Upgrade paths: Required upgrade stops, such as 19.2, 19.5, 19.8 and 19.11 in the documented sequence, must be staged through the offline media process.
- Maintenance window: Monthly minor releases and patch releases need a local test and transfer cycle.
- Recovery: Backup and restore procedures must be rehearsed inside the isolated network.
Confirm which features your enclave needs, whether each one has documented offline behavior in the version you will run, and who transfers and verifies packages across the air gap.
Small engineering groups often choose GitLab.com because it removes server work, backups and upgrades. The GitLab.com Free tier includes 5 users per top-level group, 400 compute minutes per month and 10 GiB of storage, and the Free tier on Self-Managed has no user cap in the same sense, so the trade is between metered hosted limits and unmetered operating work. A team with no platform staff should weigh the time it would spend on upgrades, which must follow the monthly minor release cadence and the required upgrade stops. The answer flips toward self-managed once the team outgrows the hosted caps or needs features that a Self-Managed install unlocks.
- Free limits: Five users, 400 compute minutes and 10 GiB of storage apply to GitLab.com Free per the pricing page.
- Operating load: Self-managed instances need someone to apply upgrades, watch disk, and run backups.
- Paid add-ons: Extra compute minutes are sold at 10 US dollars per 1,000 minutes and extra storage at 5 US dollars per month for 10 GiB, billed annually.
- Repository size: Projects on Free have an initial 10 GiB limit for Git and LFS storage, while Premium and Ultimate projects have a fixed 500 GiB limit.
- Outside help: A fixed-scope implementation or retainer can cover upgrades without adding headcount.
Confirm your user count, monthly pipeline minutes and repository sizes, then ask a partner for a written scope covering upgrades, backups and monitoring before you commit to either model.
Teams that run many pipelines each month meet the compute minute meter quickly on GitLab.com. Jobs that run on your own runners do not consume compute minutes, which means a self-managed instance paired with self-hosted runners changes the cost model rather than adding a second bill. The trade-off is that the team then operates the runner fleet, its isolation and its capacity. This situation favors self-managed when runner hardware is already available, and it favors GitLab.com when workloads are light or bursty and the team does not want to run compute.
- Metering: On GitLab.com, Free includes 400 compute minutes per month, Premium 10,000 and Ultimate 50,000.
- Own runners: Jobs on your own runners do not use compute minutes, according to the pricing page.
- Runner operations: Self-managed teams must patch, scale and isolate runner hosts, as covered in the GitLab Runner documentation.
- Storage growth: Build artifacts and container images add storage that counts against the per-project limits on hosted plans.
- Scale planning: Large user counts and high API request rates call for reference architectures that GitLab recommends for high availability.
Confirm your monthly minute consumption from recent pipeline history, the runner capacity you can staff, and whether your compliance team accepts shared hosted runners for sensitive jobs.
How data location and compliance change the decision
For GitLab self-managed vs GitLab.com, the question is less about features and more about who controls the platform that holds your code, secrets and audit trail. The cards below cover the decisions that most often decide the hosting model in regulated environments, and each one ends with what to confirm before you commit.
Where repositories and backups live
GitLab.com is currently hosted on the Google Cloud Platform in the USA, so your repositories, LFS objects, CI logs and backups sit in that provider's footprint under GitLab's control. A self-managed instance places all of that data in your cloud account, data center or on-premises racks, and backups follow the storage you choose. Check the data residency terms in your contract, where backups are replicated, and whether your retention rules can be enforced on the backup target you plan to use.
Who holds administrative access
On GitLab.com, GitLab operates the platform, so your team manages groups, projects and users but not the underlying servers, database or backup infrastructure. On a self-managed instance, your administrators hold root access to the operating system, the PostgreSQL database and the secrets files, which gives full control and also full responsibility for privileged access reviews. Ask who must approve root access, how break-glass accounts are logged, and whether the audit events your assessor expects are retained outside the GitLab host.
How authentication connects to your identity provider
Both models can use SSO, but the wiring differs. GitLab.com authenticates against an identity provider that you configure for your top-level group, while a self-managed instance connects directly to your directory or identity provider with the protocols your installation enables. Confirm which SAML or OIDC attributes you need, how group membership maps to GitLab roles, and who owns the outage plan if your identity provider is unavailable, because that failure can lock out every engineer at once.
Offline and air-gapped operation
GitLab documents running self-managed instances in offline, air-gapped environments, which GitLab.com cannot offer because it depends on a connected service. Offline operation also changes how you get updates, security scanners and the Duo Self-Hosted features, since each needs separate offline guidance. Before you choose, confirm which scanners, runners and container images your pipelines pull from the internet, and plan how you will mirror them into the enclosed network.
Upgrade ownership and evidence of change control
On GitLab.com, the service is upgraded by GitLab, and your assessor will look at the change records and the vendor's own controls rather than your upgrade runbooks. On a self-managed instance, your team or a partner such as DeployOpen runs each upgrade through the required upgrade stops, so change tickets, pre-upgrade backups and test results become your evidence. Ask for a written change procedure that records each upgrade, its rollback plan and the restore test that backs it up.
What evidence the assessment needs
A compliance assessment asks for proof that controls operate, such as access reviews, backup restore tests, configuration baselines and logs of privileged actions. DeployOpen prepares controls and evidence for these reviews, but it does not issue audit reports or certifications; independent auditors and certification bodies do that work. Start by asking your auditor which evidence they will sample, then decide whether GitLab.com's vendor documentation or your own self-managed records can answer each request.
What you pay for in each model
GitLab.com and a self-managed instance both carry a subscription line, but the rest of the bill lands in different places. On GitLab.com, the published price for Premium is 29 US dollars per user per month billed annually, and Ultimate is custom priced. Consumption charges sit on top: extra compute minutes are sold at 10 US dollars per 1,000 minutes, and extra storage at 5 US dollars per month for 10 GiB, billed annually. The main lever you control is where CI jobs run. Jobs on your own runners do not use compute minutes, so a team with heavy pipelines should price its own runner hosts against the compute minute bundle before committing. Ask GitLab for the exact seat count per top-level group, since the subscription applies to that namespace.
On a self-managed instance, the subscription is still paid, and it covers the same tier fee structure, but you also pay for everything GitLab does not host for you. Those costs are the virtual machines or Kubernetes capacity, the PostgreSQL, Redis and object storage the chosen installation method needs, backups, and the staff hours for patching, upgrades and monitoring. Upgrades matter most here. GitLab requires passage through upgrade stops, such as 18.5 and 19.5 in the published list, so budget engineer time for each planned path. Confirm which of these items a quote includes: licenses for each user, support level, and any professional services for installation, hardening or migration. Ask for the cost of a high availability build separately, because the reference architectures add components rather than replacing them. Ask the vendor to state whether pricing changes at your user count, and what happens to the subscription if your user count grows mid-term.
What your team runs in each model
This table compares who carries each operational task when GitLab runs as a self-managed instance versus GitLab.com, the multi-tenant SaaS. Read each row as a question to answer for your own team: where the cell says GitLab, the vendor operates the service, and where it says your team, you keep the work and the risk.
| Task | GitLab.com | Self-managed GitLab |
|---|---|---|
| Hosting and service operation | GitLab runs the service, currently on Google Cloud Platform in the USA according to GitLab's pricing FAQ | Your team runs the instance on infrastructure you choose, including air-gapped networks |
| Installation method choice | Not applicable to you | Your team chooses among the Linux package, Helm chart, Operator, Docker or source installs |
| Upgrades and required upgrade stops | GitLab applies upgrades to the service; your team manages groups, users and settings | Your team plans monthly minor upgrades and required stops at x.2, x.5, x.8 and x.11, such as 19.5 and 19.8 |
| Backups and restores | GitLab operates the service backups; confirm restore expectations and data location in your contract | Your team designs, tests and documents backup and restore; GitLab publishes backup and restore guidance |
| High availability at 3,000 or more users | Handled by GitLab as part of the hosted service | Your team builds Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul, as GitLab recommends |
| Security patching | GitLab patches the hosted service | Your team applies backported security fixes to supported releases, which GitLab maintains for the current and previous two releases |
| Runner hosting | GitLab offers hosted runners, with compute minutes counted per plan; your own runners do not use compute minutes | Your team hosts runners, and jobs on your own runners do not use compute minutes |
| Groups, users and runner registration | Your team manages top-level groups, users and runners in the hosted console | Your team manages instance settings, users and runners, plus the underlying identity integration |
Moving between self-managed and GitLab.com
This sequence turns a choice between self-managed GitLab and GitLab.com into a controlled move, with each step confirmed before the next begins. It produces a verified inventory, migrated projects, rebuilt pipelines and a dated cutover that your team can roll back if needed.
Confirm the target model and subscription
Decide whether the destination is GitLab.com or a Self-Managed instance before any data moves, and confirm the subscription path in writing with GitLab. Subscriptions cannot be moved between GitLab.com and Self-Managed, so a switch means buying a new subscription on the destination side, and the existing one is not carried across. Ask GitLab which transfer path applies to your account, whether any history, issue data, merge request data or access settings will not carry over, and what you will lose on the source side. The step is done when the decision, the new subscription and the list of known gaps are recorded and signed off by the budget owner and the engineering lead.
Inventory groups, projects, users and LFS storage
Build a complete inventory of top-level groups, subgroups, projects, members, service accounts, deploy keys, registry images and Git LFS objects on the source instance. Compare the storage footprint against the destination limits: GitLab.com Free allows 10 GiB of Git repository and LFS storage per project, while Premium and Ultimate allow a fixed 500 GiB per project, and user counts are limited by the tier. Flag any project that will exceed its target limit and decide whether to split it, archive it or buy the higher tier. The step is done when the inventory is a spreadsheet or export that the platform owner has reviewed line by line.
Export or migrate projects with GitLab import tools
Use GitLab's import and migrate guidance to move repositories, issues and merge requests into the destination, starting with a small pilot group of non-critical projects. Run the pilot end to end, then migrate production projects in batches, recording which data types transferred and which did not. Confirm with GitLab which features, such as certain metadata or attachments, the chosen import path preserves. The step is done when each batch has a verification pass that compares commit counts, branch lists, tags and LFS object checks against the source.
Recreate groups, memberships and access controls
Rebuild the group hierarchy, visibility settings, protected branches, approval rules and member roles on the destination, and map each identity to its authentication source. On Self-Managed, this includes configuring the authentication methods your identity provider requires, while on GitLab.com the sign-in options follow the hosted service. Review every access grant against the source inventory so that no contractor or service account is added by default. The step is done when an access review signed by the security owner matches the source inventory, with exceptions documented.
Rebuild CI variables, secrets and runners
Recreate CI/CD variables, protected and masked values, environment scopes and scheduled pipelines on the destination, and rotate any secret that passed through the old system. Runners do not move with the project: register new runners on the destination, or confirm with GitLab how your hosted runners are provisioned, and note that jobs on your own runners do not consume GitLab.com compute minutes. Check the minutes budget for pipelines that will run on shared runners, since the Free tier includes 400 compute minutes per month. The step is done when a sample pipeline for every critical project passes on the destination with the expected secrets and no leftover references to the source.
Run parallel validation and rehearse the cutover
Run a rehearsal cutover on a copy of the production projects, time each stage, and record every manual step that the rehearsal required. Confirm webhooks, integrations, container registry references, package feeds and any external links that point at the old URL. Agree the rollback point in writing, including how long the source stays read-only and which changes made during the window must be re-entered. The step is done when the rehearsal log lists no unresolved blockers and the rollback owner has approved the plan.
Cut over and retire the source
Freeze writes on the source, run the final incremental transfer, switch developer remotes, DNS entries and integrations to the destination, and announce the change to users with a clear support channel. Verify that the first production pipelines and merge requests complete on the destination before anything on the source is removed. Keep the source in a read-only state for the agreed retention period, then decommission it and remove stored credentials. The step is done when the change log shows every integration tested, the source is read-only, and the retirement is recorded with the date and approver.
Questions buyers ask before choosing a GitLab hosting model
How much staff time does a self-managed GitLab instance take?
No fixed figure is published for staff time, so the answer depends on the instance. The main drivers are user count, the architecture you choose and how often you upgrade. GitLab's reference architectures run from 1,000 users to 50,000 users, and GitLab generally recommends a high availability strategy for 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Each of those components adds monitoring, patching and backup work. Upgrades also recur: GitLab releases a minor version monthly and requires upgrades to pass through upgrade stops. Costs fall into three groups: infrastructure you pay for, subscription fees (the GitLab pricing page lists Premium at 29 US dollars per user per month billed annually), and the staff hours to run it. Ask any partner or internal team for a written estimate of hours per month, broken out by upgrades, backups, monitoring and incident response.
How long does it take to move between self-managed and GitLab.com?
No duration is published, and the answer depends on what moves. A GitLab.com subscription applies to a top-level group namespace, and subscriptions cannot move between GitLab.com and Self-Managed. Switching means buying a new subscription on the other side. The data work covers repositories, LFS objects, CI configuration, users, groups, runners, integrations and access controls. Repository count, total size, the number of users and how much CI and security configuration you depend on drive the effort most. If you are moving a running instance rather than importing projects, the upgrade path also matters, because upgrades must pass through required upgrade stops. Get the sequence, cutover window and rollback plan in writing before you commit to a date. Import tooling is described in GitLab's import and migrate documentation.
What skills does a team need to run self-managed GitLab?
The team needs Linux administration, PostgreSQL administration, Redis operations, object storage configuration and backup and restore practice. The Linux package bundles PostgreSQL, Redis and Sidekiq, and GitLab describes it as the most mature installation method, which reduces the number of separate systems you run. A high availability build adds Gitaly Cluster, Praefect, Patroni, Redis Sentinel and Consul, so the team also needs failover testing and monitoring experience. Kubernetes skills matter only if you choose a cloud-native route. GitLab documents that stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so the Cloud Native Hybrid architecture keeps those on VMs or managed services. Test restores on a schedule, because the backup procedure only protects you if restores work. Review the backup and restore documentation before you size the team.
Can our own team run self-managed GitLab without outside help?
A capable Linux and PostgreSQL team can run a single-node or modest instance, provided it has time for monthly minor releases, upgrade stops and security patching. Risk rises with scale, with high availability, and with compliance evidence requirements. Ask three questions before deciding. Who owns on-call for failover and restores? Who tests the upgrade path before each stop? Who documents controls and keeps evidence current? If the answers are unclear, the team is likely to carry a backlog of patching and restore testing. Consider a split model in which your staff run day-to-day operations and an outside party covers planning, hardening, upgrades or runbooks. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your infrastructure, under a fixed scope agreed in writing.
Can GitLab.com meet our data residency requirements?
GitLab.com may not meet residency rules that require a specific location. GitLab's pricing page FAQ states that GitLab.com is currently hosted on Google Cloud Platform in the USA. That is a current hosting fact, not a contractual commitment, so confirm the terms in writing with GitLab, including where data is stored, processed, backed up and accessed by support staff. Self-managed GitLab lets you choose the location and keep repositories, CI logs and backups inside your own cloud accounts, data centers or networks. Your obligations still apply in that case, and your compliance assessor will need evidence for the controls you implement. Ask your legal and compliance leads to map the regulation to the hosting options before you select a vendor or a region.
Does GitLab support air-gapped installations?
GitLab documents running self-managed instances in offline, air-gapped environments. The offline environments guidance is the starting point, and GitLab provides separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. Confirm each feature you plan to use against that documentation, because features that normally fetch updates, advisory data or external services need an offline alternative. Plan how packages, container images and scanner data reach the isolated network, how they are verified, and how they are updated on a schedule. Ask GitLab or your partner to confirm which features in your tier work offline, and test an upgrade in a staging network before you rely on the process in production.
When is it worth hiring a partner to run GitLab?
Hire a partner when the skills gap, the availability target or the evidence burden exceeds what your team can carry alongside its other work. Typical triggers include a move to a high availability reference architecture, a regulated environment that needs documented controls, or a platform that must be upgraded on a fixed schedule. DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
How DeployOpen approaches a GitLab hosting decision
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-managed GitLab inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. The choice between self-managed GitLab and GitLab.com is usually settled before any installation work starts, so our first step is to write down the facts that decide it: where your source code and CI logs may reside, how many users sit under each top-level group, whether you need GitLab's Ultimate security features, and who on your team will own upgrades. Those answers determine whether the work is a standalone instance, a high availability build, or a decision to stay on GitLab.com.
Most DeployOpen engagements are fixed-scope. Before work begins, the scope, deliverables and timelines are agreed in writing, so you know which items are included, such as the Linux package install, PostgreSQL and object storage configuration, backup and restore testing, and the runbooks for upgrade stops. Ask any provider, including us, to name the GitLab version you will start on, the maintenance window used for monthly minor releases and the required upgrade stops your path crosses, and to state how each item is verified. Quotes should separate one-time build work from recurring operations so the cost of running the instance is visible before you commit.
DeployOpen is not a GitLab partner or reseller, so a GitLab subscription is bought from GitLab or a GitLab reseller and is separate from our services. Our work is the planning, implementation and operating support around the instance. Ongoing support, upgrades and continuous testing are available as a retainer, which suits teams that want someone accountable for monthly minor releases and security patch windows after the initial build. Confirm with GitLab directly which subscription terms, activation process and support entitlements apply to your deployment before you finalize scope.
How DeployOpen scopes, delivers and supports self-hosting
If you choose self-managed GitLab, the first deliverable is a written scope that names who operates each layer. DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the scoping conversation starts with where the instance will run, which GitLab installation method fits your team (the Linux package, the Helm chart, the GitLab Operator, Docker or source), and whether the PostgreSQL, Redis and object storage components are bundled or external. Decisions about user count, the single-node or high availability reference architecture, and whether Geo is needed are recorded in writing before build work starts. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work begins, and quotes follow from that written scope.
Hardening, backup testing and upgrade planning are where self-managed GitLab most often drifts, so each gets a named deliverable. Implementation covers the configuration that GitLab's hardening guidance describes, plus the integration points your identity provider and runners depend on. Backup and restore is tested rather than assumed: the team restores a backup from the GitLab backup and restore procedure into a separate environment and records the result. Upgrade planning maps each target release against the required upgrade stops and the monthly maintenance cadence, so your team knows which versions to plan for. Documentation of every decision and control is delivered alongside the system so your own staff can operate it.
Ongoing support, upgrades and continuous testing are available as retainers, and the terms should be confirmed before you sign. Once the instance is live, the operating work your team takes on is the monthly minor release, the security patch cycle and the periodic restore test. Ask for the retainer scope in writing: which upgrades are included, how security findings are triaged, what response expectations apply and whether security testing of the instance is part of the agreement. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification, so confirm with your assessor which evidence they will need.
