GitLab security hardening guide for self-managed instances

Why GitLab security hardening starts before the first user signs in

If you are standing up a self-managed GitLab that will hold source code and CI/CD secrets, or inheriting one that already does, the decisions about what to lock down belong before the first user signs in. Hardening is a set of application, configuration, host, runner and patching controls, applied in a deliberate sequence and then verified. Each layer depends on the one below it, so a clean admin screen does not prove the operating system, the runners or the token policies are in the state you intended.

The work is harder than it looks for three reasons. First, several settings default to open, including sign-up behavior and what a new account can do until someone changes it. Second, a single control can live in many places: the Admin Area, the gitlab.rb configuration file, the operating system under the instance, the runner hosts that execute jobs, and the personal, project and group access tokens that people create themselves. A control set in one place and contradicted in another is a common source of findings. Third, GitLab's hardening guidance, which covers application settings, CI/CD, configuration files, the operating system and NIST SP 800-53 oriented controls, describes itself as a work in progress to be rolled out gradually. Your team has to decide which recommendations apply to your risk, in what order, and what you will accept and document where they do not fit.

Hardening also does not end at go-live. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and the maintenance policy backports security fixes to the previous two monthly releases as well as the current one. Each upgrade can change defaults, add settings or reset values you tuned, so the hardened baseline needs to be re-checked after each change. Plan an owner for that review, a written baseline that records each setting and its reason, and a standing check that compares the running instance against that baseline.

Before you start, confirm three things with your team: who approves exceptions to the baseline, where configuration and secrets are stored and who can read them, and which compliance framework, if any, the evidence must map to. DeployOpen configures controls, tests them and prepares the evidence an assessor will ask for. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your assessor early which artifacts they expect.

Which GitLab settings, files and runner controls carry the hardening

Hardening a self-managed GitLab instance is spread across several surfaces: the web application, the configuration file that drives the Linux package, the host operating system, CI/CD settings and the runners that execute jobs. The cards below map each surface to the decisions it holds and the checks worth running before and after changes.

Application settings and sign-up policy

The Admin Area holds sign-up restrictions, password and two-factor policy, default session and project visibility, and related access controls. Decide who may create accounts, whether new projects default to private, and whether two-factor authentication is required, then record each choice. Review these settings after every upgrade, because defaults and available options can change between releases.

The gitlab.rb configuration file

The gitlab.rb file in the Linux package configuration directory controls many server-side behaviors, including external URL, TLS, backup settings and component options. Keep it under version control with restricted file permissions, and treat it as a hardening artifact: each change should be reviewed and reapplied with the reconfigure step. Store the secrets files separately, since they are required for a restore.

Operating system and network boundary

The host operating system, its patch level, SSH access, firewall rules and exposure of ports 80 and 443 determine what an attacker can reach before GitLab's own controls apply. The GitLab hardening guidance includes operating system recommendations, so check it against your distribution's baseline. Confirm which administrative paths, such as SSH and database ports, stay closed to user networks.

CI/CD protected variables and branches

Protected variables are exposed only to jobs running on protected branches or tags, and protected branches restrict who can push and merge. Together they keep deployment credentials away from unreviewed code. Confirm which roles can change pipeline settings, and review whether job tokens and pipeline inclusion are restricted to the projects that need them.

Runner registration and executor choice

GitLab Runner executes jobs on machines you operate, so registration scope and executor type define the blast radius of a compromised job. Shared runners reach many projects, while project or group runners limit exposure. Choose the executor (shell, Docker or autoscaling) based on isolation needs, keep Runner versions aligned with GitLab, and confirm that untrusted merge requests cannot run on privileged runners.

Personal and project access tokens

Personal access tokens, project access tokens and group tokens authenticate automation and users outside the browser session. Review scopes, expiry dates and ownership, and retire tokens tied to departed staff. Confirm with the product documentation which token lifecycle controls, such as expiry enforcement or rotation policies, are available in your tier before you write them into your standard.

Audit events and tier availability

Audit events record administrative and permission changes, and they are the evidence you will need for access reviews and incident investigations. Decide where events are retained and who reviews them. Some audit and compliance features belong to higher tiers, so confirm availability for your edition against the GitLab pricing and product documentation before you design the review process around them.

Which hardening controls to enforce now and which to phase in

This table compares common GitLab hardening settings by what they protect, when to enforce them immediately and when to phase them in. Read each row as a trade-off: the control reduces a specific exposure, and the operational cost falls on developers, integrations or your platform team. Most instances should enforce identity and sign-up controls first and phase in runner isolation and token policy changes after inventorying what depends on them.

Decision	When it fits	Operational cost
2FA: all users at once or by group	Enforce at once for administrators and small teams; phase in by group with a grace period for large or mixed user bases	At once: lockouts and help-desk load on day one. Grace period: longer exposure window and tracking of who has not enrolled
Sign-up: open or approval-based	Approval-based or invitation-only for regulated or internal-only instances; open only where external contributors are expected	Approval adds a request queue and onboarding delay; open sign-up requires ongoing review of unexpected accounts
Runners: shared or dedicated for sensitive projects	Dedicated runners for projects handling production credentials or regulated data; shared runners for low-risk build work	Dedicated runners need their own capacity, patching and tagging; shared runners risk cross-project data exposure
Executor: shell	Trusted, single-purpose build hosts where the team controls every job	Jobs share the host filesystem and user, so one job can affect others; hardest to isolate
Executor: Docker	Most build jobs where containers give per-job isolation without full VM overhead	Privileged mode or host socket access weakens isolation; image sourcing needs review
Executor: autoscaling	Sensitive or bursty workloads that should run on fresh, disposable machines	Requires cloud or hypervisor capacity, image maintenance and a scaling policy to set up and monitor
Protected variables and branches versus developer flow	Protect production deploy credentials and release branches; keep test-only variables unprotected	Developers cannot read or push to protected refs without maintainers, which slows hotfixes and needs a documented exception path
Token lifetime and scope versus integration breakage	Shorten lifetimes and narrow scopes for personal and service tokens as integrations are inventoried and moved to owned service accounts	Short lifetimes break scripts and bots on expiry; narrower scopes fail silently until each consumer is found
NIST SP 800-53 mapping: full set or risk-based subset	Full set when an assessor requires it for a defined boundary; risk-based subset to start, with the rest documented as planned	Full set means evidence collection for many controls; a subset needs a written rationale and a review date
In-place hardening or rebuild from a hardened baseline	In-place for a stable instance with a tested backup and restore; rebuild when configuration drift or unknown changes make the current state hard to trust	In-place needs careful change windows and rollback plans; rebuild requires data migration, cutover and a parallel period

How to harden a self-managed GitLab instance in sequence

The sequence moves outward from the platform baseline: a supported version and host, then exposure and access, then configuration, CI/CD and credentials, and finally evidence and patch intake. Each step ends with a check you can repeat, so the hardened state is confirmed by evidence.

Fix the platform baseline first
Confirm the instance runs a release on the line GitLab's maintenance policy currently covers, and that your team knows which releases still receive security fixes. The platform engineer checks the installed version and the host operating system against your hardening baseline, including patch level, time synchronization, and the accounts and services allowed on the host. Confirm the operating system is still supported by its vendor. The step closes when the version, OS release and host inventory are written down and match the baseline, and any gap has an upgrade ticket that follows the required upgrade stops.
Limit network exposure and terminate TLS
Decide which ports and paths the instance exposes, place it behind your load balancer or reverse proxy, and terminate TLS with certificates from your own certificate authority or an approved public issuer. The network engineer closes direct access to database, Redis and Gitaly ports from outside the application tier and restricts administrative paths to management networks. Confirm the TLS protocol and cipher policy with your scanner. The step closes when a port scan from outside the allowed networks shows only the intended listeners and an external TLS test reports the protocol versions your policy requires.
Set sign-up and visibility defaults
In the admin area, decide whether self-registration is allowed, who may create groups, and what default visibility new projects and groups receive. Many regulated teams disable open sign-up and default to private visibility, then grant exceptions through groups. The administrator records each setting and its owner. The step closes when a test account created outside your identity process cannot register, and a new project created by a standard user defaults to private visibility.
Enforce authentication policy and two-factor authentication
Connect the instance to your identity provider using the authentication methods listed in GitLab's authentication documentation, and decide which sign-in paths remain local. Require two-factor authentication for all users in the admin settings, set password and session options that match your standard, and define how the root account is protected and used. Confirm that service accounts and tokens are not used for interactive sign-in. The step closes when a test user without a second factor is prompted to enroll, and an unauthenticated request to a private project's API and Git endpoints returns an authentication failure.
Review gitlab.rb changes in version control
Keep gitlab.rb under version control, with each change reviewed by a second engineer before it reaches the server. The platform engineer compares the proposed file with the running configuration, applies it with a reconfigure, and keeps the output as a record. Secrets stay in your secret store and are referenced from the file without being committed. The step closes when the difference between the committed file and the running configuration is empty after reconfigure, and every setting traces back to a reviewed commit.
Harden CI/CD protections and runner scope
Mark sensitive CI/CD variables as protected and masked where your version supports it, and protect the branches and tags that deploy to production. Restrict each runner to specific projects or groups, prefer executors that isolate jobs from the host, and limit who can register runners. Review the runner registration settings so a new runner cannot be attached with a broadly scoped token. Build owners confirm which jobs need protected variables. The step closes when a pipeline on an unprotected branch cannot read a protected variable, and a runner registered for one project does not pick up jobs from another.
Set token policies and route audit events
Inventory personal, project, group and deploy tokens, set expiry and scope limits in line with your policy, and rotate tokens that predate it. Owners replace tokens that automation depends on, then revoke the old ones. Turn on audit events and send them to your log store, with retention set by your records policy. The step closes when a revoked token fails an API call, and a test event such as a token creation or permission change appears in the log store within the ingestion window you agreed.
Document control mapping and schedule patch intake
Map each configuration, process and log in this sequence to the control IDs in the framework your organization uses, such as NIST SP 800-53 for many public sector programs. The mapping shows where evidence lives and who owns it. Then schedule patch intake: track monthly and patch releases, assess security fixes, and plan upgrades through the required upgrade stops. The step closes when every mapped control has a named owner and an evidence source, and the patch calendar has a named reviewer. Confirm the mapping with your assessor, because DeployOpen prepares evidence but does not issue assessment results.

What drives hardening effort and how to keep each part down

This table lists the factors that change how much work a GitLab hardening project takes, with a practical way to keep each one contained. Read it as a checklist for scoping: the left column names the driver and the right column names the lever you control. The main takeaway is that most effort sits in finding existing exceptions and testing what breaks, not in applying the settings themselves.

Driver	Why it changes effort	How to keep it down
Users and groups needing policy exceptions	Every sign-up rule, 2FA requirement or token limit that a team cannot meet becomes an exception to record, review and retest.	Inventory current exceptions before changing anything, retire stale ones, and confine remaining exceptions to named groups with an expiry date.
Projects and CI pipelines touching sensitive secrets	Each pipeline that reads protected or masked variables must be checked for scope, branch restrictions and any printed output.	Move secrets to protected, scoped variables, limit which branches can read them, and remove unused variables in the same pass.
Runners and executors across hosts or clouds	Each runner type, tag and host has its own isolation, patching and registration settings, and shared runners widen the blast radius.	Standardize on a small set of runner templates, separate runners by sensitivity, and keep runner versions aligned with the GitLab version.
Deployment model: single Linux package node	A single node has one configuration file and one OS baseline, so changes are fewer but every restart affects all services.	Keep gitlab.rb and OS settings in version control and schedule changes in maintenance windows with a tested rollback.
Deployment model: multi-node reference architecture	Settings are repeated across nodes for Gitaly, PostgreSQL, Redis and application servers, so drift between nodes is a common failure.	Build one baseline and apply it to every node from the same source, then compare configuration on each node after every change.
Deployment model: Kubernetes with external stateful services	Hardening spans the cluster, the chart values, the Kubernetes network policy and the external databases, each owned by a different team.	Agree on ownership for each layer first, and keep stateful services on VMs or managed services as the reference architecture describes.
Deployment model: air-gapped	Patches, scanner data and images must be transferred across the boundary, which adds steps to every patch cycle and to validation.	Plan the transfer path and approval steps before the first hardening change, and test one full offline patch on a staging instance.
Identity provider and token-dependent integrations	Changes to session length, token scopes or 2FA enforcement can break SSO logins, service accounts and external tools that hold tokens.	List every integration that uses a personal access token, project token or OAuth app, then rotate and test them in a staging copy before production.
Depth of control mapping required	A mapping to NIST SP 800-53 control IDs or an internal policy requires evidence for each control, and the amount of evidence grows with each control in scope.	Agree the control set in writing at the start, map only the controls in scope, and collect evidence from the same settings used in the build.
Change control for gitlab.rb and OS changes	Each edit to gitlab.rb or the operating system needs a request, review, test record and rollback plan if the organization requires them.	Batch related changes into fewer change requests, keep a dated record of each reconfigure, and use version control diffs as the review artifact.

How patch cadence and audit review keep hardening from drifting

Hardening decays without a routine. A sign-up restriction, a 2FA requirement or a protected variable that was correct at go-live can change through a version upgrade, an edit to gitlab.rb, an operating system package update or a new administrator account nobody reviewed. The GitLab maintenance policy sets the rhythm you need to plan around: a minor release on the third Thursday of each month, patch releases twice a month, and currently maintained lines 19.5, 19.4 and 19.3. Treat that cadence as a standing calendar item with a named owner, reviewed on a fixed schedule rather than checked only when a notification arrives.

Start by deciding who triages security patch releases. Name a primary owner and a backup from platform engineering, and require security sign-off for any change that touches authentication, runner registration or token settings. The maintenance policy says bug fixes are backported only to the current stable release, while security fixes are also backported to the previous two monthly releases. An instance on an older monthly line may still receive a security fix, but it will not receive ordinary bug fixes, so the triage owner should confirm which line each instance runs before setting urgency. Write down the triage decision, including who may defer a patch and the conditions for deferral.

Agree how quickly each patch reaches a non-production copy and what is checked there before production. The copy should match production's gitlab.rb, operating system packages, Runner versions and authentication configuration, or the test proves little. After each upgrade, re-verify the settings that upgrades and package changes disturb most often: sign-up restrictions, 2FA enforcement, token expiry, default project visibility, Runner registration, protected variable scope and the permissions on the secrets file. Keep the check as a written list so the same items run every time, and store the result beside the change ticket. Confirm each setting against the hardening documentation for your installed version, since that guidance is still being rolled out gradually.

Review audit events on a schedule the team can sustain, and make each review produce a record. Look for changes to administrator roles, sign-up and authentication settings, group membership and personal access token creation, and match each change against an approved ticket. Setting drift is the gap between the configuration you approved and the configuration actually running, so compare gitlab.rb and key application settings against a saved baseline on a regular basis, and investigate any difference that has no ticket behind it. Required upgrade stops are a separate planning item covered in the GitLab upgrades and support topic, so schedule patch testing around them and do not treat them as optional.

How hardening differs by deployment model

The Linux package is the most direct starting point for hardening. Most controls live in one configuration file, /etc/gitlab/gitlab.rb, on one host, and the bundled PostgreSQL, Redis and Sidekiq components run on that same server. A reviewer can read the full configuration in one place, which makes this model the easiest to baseline and to explain to an auditor.

What changes:

Sign-up restrictions, password policy, session lengths and other application settings are applied through gitlab.rb and then reconfigured on the single host.
Operating system controls such as SSH access, firewall rules, file permissions on the secrets file and time synchronization all sit on one machine.
Backups of gitlab.rb and the secrets file must be stored separately from the GitLab data backup, because both are needed for a restore.
Runner isolation is a separate host or network decision, since runners are not bundled with the instance.

What stays the same:

The same hardening topics apply: sign-up restrictions, two-factor authentication, token policies, protected variables and audit events.
Patch intake follows the same monthly minor release and security backport cadence.

Before you rely on a baseline, confirm with the GitLab hardening documentation which gitlab.rb settings apply to your installed version, and check the Linux package installation notes for the operating system you run.

Access control and secrets handling specific to GitLab hardening

Build steps alone do not protect a GitLab instance if the people, tokens and secret material around it are loosely controlled. The cards below cover the access and secrets decisions that sit beyond the operating system and gitlab.rb settings, and they are the items auditors and security reviewers usually ask about first.

Separate the secrets file from backups

The gitlab.rb secrets file holds the encryption keys GitLab uses for database-stored secrets, so a backup without it may not restore a working instance. Store that file separately from routine backups, under key management controlled by your organization. The backup sibling topic covers the backup process in depth. Check that the copy location, access list and rotation owner are written down.

Restrict administrator and service accounts

Limit the number of users with administrator access and confirm that each admin account is named, individually assigned and protected with two-factor authentication. Service accounts used by integrations and runners should have only the group or project access they need. Review both lists on a fixed schedule and remove accounts that no longer have an owner.

Limit token scope and expiry

Personal, project and group access tokens should carry the narrowest scopes that the integration needs and an expiry date. Long-lived tokens with broad write scope are a common path to repository and pipeline compromise. Ask who creates tokens, where they are stored, and how revocation is handled when an integration owner leaves.

Keep runner tokens out of pipelines

Runner registration tokens and runner authentication tokens let a machine join or act for an instance, so they must never appear in .gitlab-ci.yml, job variables or repository files. Register runners through a controlled process, and rotate tokens after any suspected exposure or when a runner host is retired. Verify this with a search of repository history and CI settings.

Expose protected variables only to protected refs

Mark variables that hold deployment credentials as protected so they reach jobs only on protected branches and tags. Pair this with masking for values that must appear in logs and with a review of which jobs can run on unprotected branches. Test the setting with a merge request from a fork or feature branch to confirm the secret is not visible.

Prevent secrets in job logs

Masking hides matching values in job output, but it only works for values that meet the masking rules and are not echoed in transformed forms such as encoded or split strings. Avoid printing environment variables in scripts, disable debug tracing for jobs that handle secrets, and review sample job logs during the hardening check. Treat any secret that reached a log as exposed and rotate it.

Restrict changes to CI/CD and runner assignment

Decide who can edit CI/CD settings, pipeline configuration and runner assignment to a project or group. Changes to runner assignment can redirect jobs, and changes to CI/CD configuration can alter what runs with access to secrets. Keep these permissions with a small set of maintainers, require review of changes to pipeline files, and check the audit trail for changes made outside that group.

How to test that hardening holds and fails safely

A hardening change is only proven when you try to break it. The verification plan for a self-managed GitLab instance should be built from negative cases, each one a specific action that must be refused or recorded. Write them down before the change window and assign an owner to each. Start with the access controls: an unauthenticated browser session must not be able to create an account where sign-up is restricted, and an account without two-factor authentication must be blocked once the enforcement date you set has passed. Test the second case with a real account that is not yet enrolled, not with an administrator whose session may already carry exemptions. Next, test the CI/CD boundaries, which are where most hardening gaps show up in practice. Create a throwaway project with a branch that is not protected, add a job that prints a protected variable, and confirm the job receives nothing. Then register a runner to one group and submit a job from another group's pipeline to confirm it stays queued. Repeat the exercise with a token that has expired, a token scoped to a project it was not issued for, and a token whose permissions exceed the role you intended. Each request should return a refusal, and the refusal should appear in the logs you will later hand to an assessor. The audit trail needs the same treatment. Perform privileged actions on purpose, such as changing a sign-up setting, adding a deploy key, altering a protected branch rule or promoting a user, and confirm that an audit event exists for each one. Then confirm that the event has left the instance and arrived in your log store with the expected fields and timestamps. An audit event that sits only on the GitLab host does not satisfy most review questions about retention or independent review. The exact list of auditable events and the export options depend on your GitLab tier and version, so confirm both against the documentation for the version you run. Failure modes matter as much as the happy path. Test a deliberately broken gitlab.rb change in staging, such as a malformed value or a setting that conflicts with another, and confirm that your pre-reconfigure validation or review step catches it before reconfigure runs. Then run the change through the production process and check that a failed reconfigure leaves the previous configuration in place. Keep a dated copy of the configuration files and secrets from before each change, and rehearse restoring them. Document the rollback steps, who may trigger them, and how long your own team judges a rollback to take, since no general duration applies to your environment. Keep the results as a dated evidence pack: test IDs, the exact commands or steps, screenshots or log excerpts, the staging and production versions tested, and the person who signed off. DeployOpen prepares this evidence and the controls behind it for assessors, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so ask your assessor early which evidence format they expect.

What buyers ask about GitLab hardening cost, effort and ownership

What drives the cost of a fixed-scope GitLab hardening project?

The price follows the written scope, not a standard rate card. DeployOpen does not publish a price list, and a quote is built from the agreed scope, deliverables and timeline. The main drivers are the number of instances and nodes in scope, how many configuration areas are covered (application settings, gitlab.rb, operating system, CI/CD runners, token policies, audit events), how many policy exceptions need documenting, how many integrations such as identity providers or artifact stores must be verified, and how deep the control mapping goes. Ask for a quote that lists each of these as a separate line, states what is one-time work (baseline, configuration, testing, evidence) and what recurs (patch intake, re-verification), and names what the client team must provide.

How long does GitLab hardening take and what changes the timeline?

Duration depends on scope size and on how quickly decisions and access arrive. Instead of a generic figure, ask for a schedule tied to the written scope. The factors that move it most are instance size and the number of nodes, how many exceptions to the baseline must be argued and approved, the number of integrations to test, the depth of the NIST SP 800-53 oriented control mapping, and how often production change windows are available for restarts and reconfiguration. Hardening is usually rolled out gradually, because GitLab documents its hardening guidance as a work in progress, so the plan should include staging validation before production changes.

What does our team need to provide during a GitLab hardening engagement?

Named owners and decisions matter more than hours. Expect to supply administrative access to the instance, the operating system and the cloud or data center accounts that host it, plus change windows for restarts and reconfiguration. Assign an owner for identity (sign-up rules, two-factor policy, SSO), one for runners (executor types, isolation, protected variables), and one for backups (storage, retention, restore testing). Someone with authority must decide each policy exception, such as allowing a sign-up method or a token lifetime that deviates from the baseline. Confirm these owners and decision dates in the scope before work starts.

Can our internal team harden GitLab without an outside partner?

Yes, if the team has the skills and time to own the work end to end. The effort is mostly Linux administration, GitLab configuration (gitlab.rb and application settings), CI/CD runner security, identity configuration and evidence collection. Internal teams often underestimate the verification and documentation work: each control needs a test, a record of the result and a link to the policy exception process. Ask whether your engineers have run GitLab upgrades, can read the hardening guidance critically, and can test restores. If one of those skills is missing, a fixed-scope project can cover the gap while your team learns the configuration.

Which GitLab tier features are needed for audit logging or token controls?

Some controls depend on the edition, so confirm them before buying. GitLab's pricing page lists application security testing, software supply chain security, vulnerability management and compliance features as part of Ultimate, while Premium includes advanced CI/CD and priority support. Free, Premium and Ultimate are all available for self-managed installations. Do not assume a specific audit event, token policy or compliance report is available in your tier. Map each required control to the feature that provides it, then check the feature matrix on the GitLab pricing page and the relevant GitLab documentation for your installed version, and record the result in the scope.

Does GitLab hardening replace an independent audit?

No. Hardening prepares systems and evidence, and an independent auditor or certification body decides the outcome. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Hardening reduces configuration gaps and produces records such as baselines, test results and exception approvals that an assessor can review. Confirm with your assessor which evidence they expect, which control framework applies to your environment, and whether they will accept the configuration decisions documented in the project.

What ongoing GitLab security work remains after handover?

Hardening drifts without a patch and review routine. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and it backports security fixes to the previous two monthly releases as well as the current stable release. Ongoing work includes triaging each release for security impact, scheduling upgrades that pass through required upgrade stops, rechecking configuration after changes, re-running token and sign-up reviews, and confirming that backups still restore. This recurring work can be kept in-house or covered by a DeployOpen retainer for ongoing support and periodic re-verification. Ask for the cadence and deliverables in writing.

How DeployOpen scopes, hardens, hands over and supports GitLab controls

DeployOpen plans, implements, hardens, documents and supports self-hosted GitLab inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. Each engagement is fixed-scope, with the controls, deliverables and timeline agreed in writing before hardening work begins.

How we scope

Inventory the instance settings, gitlab.rb files, operating system baseline and runner fleet in scope for the written agreement.
Confirm which sign-up, two-factor, token, protected variable and audit event controls your policy requires before any change is made.
Agree in writing which NIST SP 800-53 oriented control areas the work maps to, and which evidence the client will receive.

How we build

Apply hardening in stages, starting with application settings, then configuration files, operating system settings and CI/CD controls.
Isolate runners and protect variables, then test that pipelines on protected branches still run with the access they need.
Verify each control with a documented check, recording the before and after state so reviewers can reproduce the result.

How we hand over

Deliver a configuration record covering every changed setting, its reason, its owner and the rollback steps.
Document the patch cadence, backup dependencies such as secrets and configuration files, and the audit events your team should review.
Walk your administrators through the runbooks so they can repeat the checks without DeployOpen present.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope hardening work is accepted.
Review new GitLab releases and security patches against the hardened baseline before your team applies them.
Re-run the agreed verification checks after upgrades, so drift from the hardened configuration is found early.