Gitlab hero border pattern left svg Gitlab hero border pattern right svg

RM.2.01 - Internal Audits Control Guidance

RM.2.01 - Internal Audits

Control Statement

GitLab establishes internal audit requirements and executes audits on information systems and processes.

Context

Audits are meant to validate processes and check to see if these controls we have implemented are having the desired effect and are performed the way we intended. Internal audits have a bad reputation, but these internal audits help the audit and compliance teams to build the information they need to be the main point of contact with external audits when needed. Successful internal audits can help keep external auditors away from GitLab team-members unless absolutely necessary.

Scope

This control applies to all systems within our production environment. The production environment includes all endpoints and cloud assets used in hosting GitLab.com and its subdomains. This may include third-party systems that support the business of GitLab.com.

Ownership

Guidance

Internal audits should be a process that all GitLabbers feel comfortable being transparent about how the related process is working and what the outcome of that process is. Full transparency in an internal audit can help ensure all processes are effective prior to an external audit.

Additional control information and project tracking

Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the Internal Audits control issue.

Examples of evidence an auditor might request to satisfy this control:

Policy Reference

Framework Mapping