## Background gitlab~12052083 ran a problem validation research piece earlier in the year to gain better insight into the compliance frameworks and regulatory requirements that GitLab customers are most commonly challenged by, and how these challenges surface. The overarching goals of that research piece was to: 1. Understand the top frameworks and regulatory requirements challenging our customers today; and 2. Identify the largest pain points for managing these frameworks. (e.g. for SOC 2, `enforcing 2 person approvals` or understanding if they are adhering to this requirement may be the primary challenge) The outcome of the research piece resulted in us understanding not only the key requirements that users would like to be able to have as checks within GitLab, but it also surfaced additional opportunities that users would like to fully round out the features of the standard adherence report ## Problem One of those additional opportunities that was raised during the research piece was that users were asking for the ability to upload/store compliance documentation directly in GitLab alongside the defined requirement. This is due to several reasons: * Compliance managers require a centralised repository for storing and accessing all compliance related documents, policies, procedures and evidence. This ensures that the documentation is organized, easily retrievable and accessible to relevant stakeholders, particularly auditors * Due to having a centralised repository, this enablsed sharing of compliance reports and evidence based on the uploaded documentation. This saves time and effort compared to manually compiling reports and evidence for audits or regulatory submissions. * Being able to link specific documentation against requirements may be the evidence that is required to be showed in order to prove that those requirements are being met by the organization for audit purposes. The kinds of documentation that may be useful to keep can include the following: ### **Information Security Compliance** * ISO 27001 certification audit reports * Risk assessment reports for information security * Information security policies and procedures * Penetration testing reports * Vulnerability scan results * Incident response plans ### **Data Privacy Compliance** * Data protection impact assessments (DPIAs) * Data mapping and flow diagrams * Records of processing activities * Data subject access request logs * Employee data privacy training records * Third-party vendor data processing agreements ### **Financial Compliance** * SOX (Sarbanes-Oxley) control testing documentation * Financial audit reports * Anti-money laundering (AML) program documentation * Know Your Customer (KYC) procedures * Conflict of interest disclosure forms ### **Healthcare Compliance** * HIPAA risk assessments * HIPAA policies and procedures * Business associate agreements * Breach notification logs * Employee HIPAA training records ### **Environmental Compliance** * Environmental impact assessments * Hazardous waste management plans * Air emission monitoring reports * Water discharge permits * Chemical safety data sheets ## Questions to answer 1. What kind of documentation would they like to upload? How will these documents be paired up with requirements in GitLab? 2. Who has access to these documents? Who will have permission to upload and download these documents? 3. Do we want to have this functionality within GitLab? This brings us closer to being a GRC but that's not our stated objective, as we only want to be a GRC within GitLab itself. Would it be better to partner with a GRC around this instead? 4. Is this even necessary? It would be better perhaps if we are able to provide documentation _from_ GitLab, which is necessary for any audit, and have that documentation uploaded into a GRC instead. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->