--- layout: default title: Financial Services Compliance Support suppress_header: true --- .blank-header = image_tag "/images/home/icons-pattern-left.svg", class: "image-border image-border-left", alt: "Gitlab hero border pattern left svg" = image_tag "/images/home/icons-pattern-right.svg", class: "image-border image-border-right", alt: "Gitlab hero border pattern right svg" .header-content %h1 Financial Services Regulatory Compliance %p Learn how GitLab can help solve your compliance challenge. = link_to "/sales/", class: "btn cta-btn orange" do Contact Sales .toc-links = link_to "Regulators and regulations", "#regulators" = link_to "Regulations", "#regulations" = link_to "Common controls", "#common-controls" = link_to "Compliance Roadmap", "#compliance-roadmap" .gitlab-content-container.padding-top0 .content .tile %p GitLab is used extensively to achieve regulatory compliance in the financial services industry. Many of the world's largest financial institutions are GitLab customers. This page details the relevant rules, the principles needed to achieve them, and the features in GitLab that make that possible. .content %h2.content-title#regulators Regulators %p Examples of regulators include the following: %ul %li America: %a{ href: "https://www.federalreserve.gov/" } FEB in the US, also see the %a{ href: "https://ithandbook.ffiec.gov/" } FFIEC IT Handbook %li Europe: %a{ href: "https://www.fca.org.uk/" } FCA and %a{ href: "https://www.bankofengland.co.uk/prudential-regulation" } PRA in the UK, %a{ href: "https://www.finma.ch/en/" } FINMA in Switzerland %li Asia: %a{ href: "http://www.mas.gov.sg/" } MAS in Singapore and %a{ href: "http://www.hkma.gov.hk/eng/index.shtml" } HKMA .content %h2.content-title#regulations Regulations %p Examples of relevant regulations include the following: %ul %li GLBA Safeguards rule requires that financial institutions must protect the consumer information they collect and hold service providers to same standards. %li Dodd-Frank’s purpose is to promote the financial stability of the United States by improving accountability and transparency in the financial system. It sets the baseline for what is “reasonable and appropriate” security around consumer financial data. You must be ready to prove your security controls and document them. %li Sarbanes Oxley (SOX) exists to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes. Advice for achieving this is augmented by other frameworks such as COBIT14 and the CIS Critical Security Controls. %li PCI DSS is intended to maintain payment security and is required for all entities that store, process or transmit cardholder data. It requires companies using credit cards to protect cardholder data, manage vulnerabilities, provide strong access controls, monitor and test, and maintain policy. .content %h2.content-title#common-controls Common controls %p Specific controls common amongst these regulations are outlined below, along with features of GitLab that aid in their compliance. %table.tile %colgroup %col{ style: "width: 40px" } %col{ style: "width: 260px" } %col{ style: "width: 400px" } %col{ style: "width: 400px" } %tr %th Control %th Rule %th Principles %th How GitLab helps %tr %td Segregation of Incompatible Duties (SODs) %td To protect a system from unauthorized changes and fraud, organizations must establish organization-defined duties and roles, document separation of duties of these individuals and roles, and define associated system access authorizations to support these separation of duties. %td %ul %li You never merge your own code. %li All code needs to be peer reviewed. %li Only authorized people can approve the code. %li You need a log of who approved it. %td %ol %li %a{ href: "https://docs.gitlab.com/ee/user/permissions.html" } Defined Project Permissions %li %a{ href: "https://docs.gitlab.com/ee/user/project/protected_branches.html" } Protected branches %li %a{ href: "https://docs.gitlab.com/ee/ci/environments/protected_environments.html" } Protected environments %li %a{ href: "https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html" } Merge request approvals %li %a{ href: "https://docs.gitlab.com/ee/api/protected_branches.html#protect-repository-branches" } Unprotect permission %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ce/issues/44041" } Future: Approval jobs in CI pipelines %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ee/issues/7176" } Future: Two-person access controls %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ee/issues/4418" } Future: Require merge request approval by code owners %tr %td Identity and Access Approval Controls to Ensure Proper SODs %td Separation of duties addresses the potential for abuse of authorized privileges and helps to reduce the risk of malevolent activity without collusion. %td %ul %li Divide mission functions and information system support functions among different individuls/roles. %li Segregate configuration management, programming, system management, quality assurance functions. %li Only authorized people can approve the code. %li Only authorized roles can merge code. %td %ol %li Role-Based Access Controls (RBAC) within protected branches and environments prevent unauthorized users from deploying to labeled environments. %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ee/issues/1979" } Future: Enable Multiple rules for merge request approvals Code %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ee/issues/3845" } Future: Prevent merge request and commit authors from self-approving %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ce/issues/53906" } Future: Identity API %tr %td Configuration Management %td NIST's Configuration Management control as outlined in NIST 800-53, Rev. 4: CM-2 establishes that baseline configurations are documented, formally reviewed and agreed-upon. As baseline configurations serve as a basis for future builds, releases, and/or changes to information systems, it is critical for organizations to have the ability to control changes and evidence the integrity of the deployment process. %td %ol %li Baseline CI/CD configurations are stored and tracked. %li Automated configuration management is employed to remove manual, error-prone processes. %li Changes to configurations are approved. %li Logs of changes are maintained. %td %ol %li %a{ href: "https://docs.gitlab.com/ee/ci/yaml/README.html" } CI/CD configurations %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ce/issues/44041" } Future: Approval jobs in CI pipelines %tr %td Configuration Change Control %td Configuration Change Control is outlined in NIST 800-53, Rev. 4: CM-3: the organization implements approved configuration controlled changes to the information system and retains a record of the configuration controlled-changes - and changes to deployment configurations. %td %ul %li All changes to baseline orchestration configurations are stored and tracked. %li Changes to configurations of protected branch and environment configurations are stored and tracked. %li Logs of changes are maintained. %td %ol %li %a{ href: "https://about.gitlab.com/handbook/marketing/product-marketing/demo/cicd-deep/" } CI/CD pipeline configuration management %li %a{ href: "https://docs.gitlab.com/ee/administration/audit_events.html" } Audit Events %tr %td Access Restrictions for Changes to Configurations and Pipelines %td ISO 27002 9 (Access Controls) and NIST 800-53, Rev. 4: CM-5 and AC-3 (Logical Access Enforcement) dictate that organizations define, document, approve, and enforce logical access restrictions associated with changes to the information system. Any changes to the software can potentially have significant effects on the overall security of the systems. Therefore, organizations permit only qualified and authorized individuals to access information systems for purposes of initiating changes, including upgrades and modifications. %td %ul %li Controls exist to prevent initiation of pipelines without requisite approvals. %li Only authorized users can deploy to production. %td %ol %li %a{ href: "https://docs.gitlab.com/ee/user/project/protected_branches.html" } Protected branches %li %a{ href: "https://docs.gitlab.com/ee/ci/environments/protected_environments.html" } Protected environments %li %a{ href: "https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html" } Merge request approvals %tr %td Security %td %p Both the NIST and the ISO security frameworks outline requirements related to developer security testing and evaluation. NIST 800-53, Rev. 4: SA -11 establishes that organization must require the developers of the information system, system component, or information service to implement a security assessment plan, produce evidence of execution of security testing, and correct flaws identified. %p As a result, business application software needs to support the following: %ul %li Evidence that data has not been modified. %li Auditing and logging of events in systems that process sensitive data. %li Log system changes in a way that those logs are resistant to tampering and accessible only to privileged users. %p Note: Application Security Testing can help identify vulnerabilities that enable unauthorized access to data, logic, and reporting. %td %ul %li Scan applications regularly for vulnerabilities. %li Establish criteria for the prioritization of vulnerabilities and remediation activities. %li Pay special attention to internally or custom developed applications with dynamic and static analysis. %li Establish secure coding as a culture, and provide qualified training on secure coding. %li Establish and document a secure development life-cycle approach that fits your business and developers. %li Combine functional testing and security testing of applications: Assess for operational bugs and coding errors. %td %ol %li %a{ href: "https://docs.gitlab.com/ee/user/application_security/sast/" } SAST %li %a{ href: "https://docs.gitlab.com/ee/user/application_security/dast/" } DAST %li %a{ href: "https://docs.gitlab.com/ee/user/application_security/dependency_scanning/" } Dependency Scanning %li %a{ href: "https://docs.gitlab.com/ee/user/application_security/container_scanning/" } Container Scanning %li %a{ href: "https://about.gitlab.com/blog/2018/07/22/gitlab-11-1-released/#security-dashboard-for-projects" } Security Dashboard %li %a{ href: "https://about.gitlab.com/handbook/product/#security-paradigm" } Security Paradigm %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ee/issues/8481" } Future: Show Dependency Scanning results in Groups Security Dashboard %p In addition to Application Security Testing to help you deliver secure apps, GitLab's own application has security to prevent unauthorized access to the application code as well as audit and logging capabilities of changes to the code. %tr %td Operations Security via Protections on Branches and Environments %td Organizations need to evidence the integrity of their production environments and critical code branches. %td %ul %li Changes to configuration of protections for branches and environments are tracked and logged. %li Organizations must have access to readily available, human-readable audit trail of all actions taken to label and protect environments. %li Controls exist to prevent unauthorized parties from running deployment jobs labeled as protected. %td %ol %li Granular user-based and role-based (RBAC) access controls for branches, environments and Kubernetes clusters supply operators the ability to determine who can deploy and to what environments. %li %a{ href: "https://docs.gitlab.com/ee/user/project/protected_branches.html" } Protected branches allow you to protect your production code pipeline. %li %a{ href: "https://docs.gitlab.com/ee/ci/environments/protected_environments.html" } Protected environments allow you to protect your environments by preventing deployments to them by certain individuals. %tr %td Auditing %td Systems must have clear audit logs to trace changes to the data and also to the logic flow. %td %ul %li Auditability of the production application: Software systems must generate all of the necessary logging information to construct a clear audit trail that shows how a user or entity attempts to access and utilize resources. %li Auditability of the software itself to detect changes in logic flow: Whether urban legend or not, the example is relevant of the developer who pockets rounding errors to his own bank account %li Logs must be resistant to tampering and accessible only to privileged users. %td %ol %li One concept of a user across the lifecycle to ensure the right level of permissions and access %li %a{ href: "https://docs.gitlab.com/ee/administration/logs.html" } Audit logs %li %a{ href: "https://docs.gitlab.com/ee/administration/audit_events.html" } Audit events %li %a{ href: "https://docs.gitlab.com/omnibus/docker/README.html#where-is-the-data-stored" } Container image retention %li %a{ href: "https://docs.gitlab.com/ee/administration/job_artifacts.html#storing-job-artifacts" } Artifact retention %li %a{ href: "https://docs.gitlab.com/ee/development/testing_guide/end_to_end_tests.html#testing-code-in-merge-requests" } Test result retention %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ee/issues/5297" } Future: Disable squash of commits %li Future: Prevent purge %tr %td Change Management %td All changes must be tracked. Compliance with Sarbanes-Oxley mandates that publicly traded companies report any material changes to the processes and systems that govern the flow of financial data so as to reduce the risk of material misstatement of financial statements. %td %ul %li Systems used to support change management procedures must retain records of changes made, of who reviewed and approved changes, and the sequence in which they were performed. %li Changes should be made in such a way that they can be rolled back to a previous version quickly and easily. Here are two examples as to why: Flash Crash and TSB Bank Disaster. %li Source control systems should prevent unauthorized changes using access control or, at least showing changes for a clear audit trail. %td %ol %li %a{ href: "https://docs.gitlab.com/ee/topics/autodevops/index.html#auto-deploy" } Automated deploy %li %a{ href: "https://docs.gitlab.com/ee/update/6.3-to-6.4.html#1-revert-the-code-to-the-previous-version" } Revert button %li %a{ href: "https://docs.gitlab.com/ee/ci/review_apps/index.html#overview" } Review apps make it easy to visualize the changes in code review and ensure changes function in a legitimate manner. %li Issues Boards that enable integration of project management tools into your change management procedures. %li %a{ href: "https://gitlab.com/groups/gitlab-org/-/epics/269" } Future: End-to-end traceability for merges %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ce/issues/51738" } Future: Blackout periods to ensure production change freezes %li %a{ href: "https://gitlab.com/gitlab-org/gitlab-ee/issues/8373" } Future: Automated incident creation integration to support change management policies %tr %td License Code Usage %td Third party and open source code use must comply with license constraints. %td %ul %li To comply with license constraints, you must track license expiration and usage. This is important to manage risk from legal costs for license agreement violations and risk to your reputation. %ol %li %a{ href: "https://docs.gitlab.com/ee/user/application_security/license_compliance/" } License Compliance .content %h2.content-title#compliance-roadmap Compliance Roadmap %p A SOC 2 (Service and Organization Controls) examination with a third party assessor is on GitLab's 2020 security compliance roadmap. Whereas we currently do not maintain an independently certified security controls certification, we do operate within an information security control framework, which can be viewed here: https://about.gitlab.com/handbook/engineering/security/sec-controls.html. %ul %li Our GitLab.com SaaS is hosted on Google Cloud Platform's (GCP) cloud infrastructure, which has SOC 2 Type II and ISO 27001 certifications. For more information on GCP's compliance posture, please see https://cloud.google.com/security/compliance/ %li For more information on our security compliance roadmap, please visit our Information Security & Compliance page (in development) .content %p THE INFORMATION PROVIDED ON THIS WEBSITE IS TO BE USED FOR INFORMATIONAL PURPOSES ONLY. THE INFORMATION SHOULD NOT BE RELIED UPON OR CONSTRUED AS LEGAL OR COMPLIANCE ADVICE OR OPINIONS. THE INFORMATION IS NOT COMPREHENSIVE AND WILL NOT GUARANTEE COMPLIANCE WITH ANY REGULATION OR INDUSTRY STANDARD. YOU MUST NOT RELY ON THE INFORMATION FOUND ON THIS WEBSITE AS AN ALTERNATIVE TO SEEKING PROFESSIONAL ADVICE FROM YOUR ATTORNEY AND/OR COMPLIANCE PROFESSIONAL.