---
layout: handbook-page-toc
title: "Sarbanes-Oxley (SOX) Compliance"
---
## On this page
{:.no_toc .hidden-md .hidden-lg}
- TOC
{:toc .hidden-md .hidden-lg}
# Sarbanes-Oxley Act of 2002
[ Sarbanes Oxley Act 2002 ](https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act)is a federal law that established auditing and financial regulations for financial reporting of public companies. This law was passed to increase transparency in financial reporting by corporations and to require a formalized system of checks and balances in each company, thereby helping protect investors from fraudulent financial reporting. SOX applies to all publicly traded companies in the United States as well as wholly-owned subsidiaries and foreign companies that are publicly traded and do business in the United States.
In order to build the confidence of the investors, the SOX regulations require the following:
* CEOs and CFOs are directly responsible for the accuracy, documentation, and submission of all financial reports as well as the internal control structure to the [ SEC ](https://www.sec.gov/).
* Internal Control Report must state that management is responsible for an adequate internal control structure for their financial records. Any shortcomings must be reported up the chain as quickly as possible for transparency.
* Companies should develop and implement a comprehensive data security strategy that protects and secures all financial data stored and utilized during normal operations.
* Companies must maintain and provide documentation proving they are compliant and that they are continuously monitoring and measuring SOX compliance objectives.
* External auditor must independently assess and certify the adequacy of controls over all known risks for the financial reporting.
Formal penalties for non-compliance with SOX can include fines, removal from listings on public stock exchanges and invalidation of [ D&O ](https://en.wikipedia.org/wiki/Directors_and_officers_liability_insurance) policies. Under the Act, CEOs and CFOs who willfully submit an incorrect certification to a SOX compliance audit can face fines and/or imprisonment.
# SOX Compliance Roadmap for GitLab
As GitLab is planning to go public in November 2020, it is important that we prepare to comply with SOX ahead of listing, as the consequences of non-compliance can be severe. Below are some of the important requirements we will need to adhere to:
Points to note:
* In the first year, an “exemption” is allowed for a new public company on [ 10-K ](https://en.wikipedia.org/wiki/Form_10-K) certification under [ 404(a) ](https://www.cpajournal.com/2016/02/01/auditors-need-know-sox-section-404a-reports/) , therefore, 10-K - 404(a) certification can be submitted for GitLab from FY 2022 (2nd year) onwards.
* Additionally, the external audit opinion on internal controls, which is required under [ sec 404(b) ](https://www.cpajournal.com/2016/02/01/auditors-need-know-sox-section-404a-reports/), is temporarily exempt for [ Emerging Growth Companies ](https://www.sec.gov/smallbusiness/goingpublic/EGC) (EGCs) for the first five years. While GitLab currently qualifies as an EGC, it is to be noted that this exemption is withdrawn if the criteria for EGCs are not satisfied in any year.
Planned timelines for SOX Implementation:
# SOX Implementation Checklist
**`1. Desktop Procedures (DTP)`**
|**#**|**Business Process**|**Process Name**|**DTP Drafted**|**Flow Chart**|**Handbook Link**|
|:---|:---|:---|:---|:---|:---|
|1|Quote to Cash|Customer account creation and Conversion of lead to opportunity|[✅](https://drive.google.com/open?id=1IUQIopkAMirX1jyHD-gvaM6DUOrAToqGnAGRQj_fZsc)|[✅](https://drive.google.com/open?id=1mq94fgmWprwDUTALQr1mOH7euYBXc9DBoWjB-kN7NJk)|[✅](https://about.gitlab.com/handbook/finance/accounting/#1-customer-account-management-and-lead-conversion-to-opportunity)|
|2|Quote to Cash|Price master management|[✅](https://drive.google.com/open?id=1cB6FSc9fZJ9FZ-znSjEFDmbfoFYQAQisSrcK1nmOCPI)|[✅](https://drive.google.com/open?id=1uOKDBA5cl0cbpfVXfJC3ODpBznNOmNnidvJzjsVOhvE)|[✅](https://about.gitlab.com/handbook/finance/accounting/#2-price-master-management)|
|3|Quote to Cash|Quote creation|[✅](https://drive.google.com/open?id=16MnRUft9I4S0ikOPPEKO3FP2AIFR0ocSqUF2IIQudRc)|[✅](https://drive.google.com/open?id=19VuhpfPQXzCQfXMTMDfZrhkUuB2RkGFO7vq8JsPC0YU)|[✅](https://about.gitlab.com/handbook/finance/accounting/#3-quote-creation)|
|4|Quote to Cash|Reseller Management|[✅](https://drive.google.com/open?id=1YnNFg-X-bmtfZRsq8iWhzB9C8i9TQA7mqmYtBjBshbw)|[✅](https://drive.google.com/open?id=1xZRkGygzMQkOXSqb1cJnvU7s4oVmwzTHFWgqM7D6_88)|[✅](https://about.gitlab.com/handbook/finance/accounting/#4-reseller-management)|
|5|Quote to Cash|Contract Management|[✅](https://drive.google.com/open?id=145dHAaPVYiF9i-aiHLXTuVU8ul3OmAMBQUzsqbbOxSw)|[✅](https://drive.google.com/open?id=194cBXx599t_3z1KyEV9kbWE8-5uu9dglA37mI8QSG5o)|[✅](https://about.gitlab.com/handbook/finance/accounting/#5-contract-management)|
|6|Quote to Cash|Invoicing to customers (Sales team assisted product sale, Web portal sale and Services)|[✅](https://drive.google.com/open?id=11MQwDXcqbI6CEWsn_Yk3HtlNzC19i1vcGz_3eS4m7Sc)|[✅](https://drive.google.com/open?id=1aXyGUASe4KJHzwJ5cMV1U-6mTXSm1kNp9SlZ2O9MFwc)|[✅](https://about.gitlab.com/handbook/finance/accounting/#6-invoicing-to-customers)|
|7|Quote to Cash|Invoice cancellations and refunds|[✅](https://drive.google.com/open?id=1WdedNiRXolB30oq3gbHj2xNn6YmhzJ8um0LVSpZp1QA)|[✅](https://drive.google.com/open?id=1eL08A1xPcg7UIy7FFsBgFcUNS3TwSPkt_I0cqJIB3aA)|[✅](https://about.gitlab.com/handbook/finance/accounting/#7-invoice-cancellations-and-refunds)|
|8|Quote to Cash|Revenue recognition (for product subscription, services)|[✅](https://drive.google.com/open?id=1k2SbNIfuQ38oxsuHBWkfdXGdwJAUQ5K7JF3-O3pdCLI)|[✅](https://drive.google.com/open?id=1zKCzRpzlKRaEReenBsTge6Be7GkbshXf0A2nqikVo94)|[✅](https://about.gitlab.com/handbook/finance/accounting/#8-revenue-recognition-and-accounting-for-other-quote-to-cash-transactions-in-net-suite)|
|9|Quote to Cash|Accounting of income from sale of merchandise|[✅](https://drive.google.com/open?id=18OKyzkU3lTcTZVWKPZtz9oDyF99DVcjvypC6MhSAVgU)|[✅](https://drive.google.com/open?id=18bk70WKJDswU7yE5vhC_LFAUMjt1LkDvrX0DVSVyZi4)|[✅](https://about.gitlab.com/handbook/finance/accounting/#9-accounting-for-income-from-sale-of-merchandise)|
|10|Quote to Cash|Accounting of income from GCP Referral|[✅](https://drive.google.com/open?id=1c8kvETI6qaHhmJCWe6BC_SSQorfacHLjG6cGkqca2eg)|[✅](https://drive.google.com/open?id=1JrFJx0YcIkuRFthOqRMn212x9QSiuIodQv0Ldjh_-nQ)|[✅](https://about.gitlab.com/handbook/finance/accounting/#10-accounting-for-income-on-gcp-referral)|
|11|Quote to Cash|Accounts receivable|[✅](https://drive.google.com/open?id=1uWa7fq6kUUWZ_9vB9A9iVhbDMl_R-KCVYtPH3CeIGFs)|[✅](https://drive.google.com/open?id=1dMLg0oWnxEmKDejQgxQ31s722JaRRDxfU62BxrBVKC0)|[✅](https://about.gitlab.com/handbook/finance/accounting/#11-accounts-receivable)|
|12|Quote to Cash|Incentive payouts to Sales executives|[✅](https://drive.google.com/open?id=18R3bhLagRtVAb1Tmt-5fkXCdutX3-v07wCpSjOKsbz4)|[✅](https://drive.google.com/open?id=1pDyColGwvg0PrgTgjmkRxwoYvUVtwaAcO1aQkJj8BKc)|[✅](https://about.gitlab.com/handbook/finance/accounting/#12-commission-payouts-to-sales-executives)|
|13|Record to Report|User Access Management in Netsuite|[✅](https://drive.google.com/open?id=1m1M0RoC0wltr7_WSA7VflR2E93MD7TLNaIxkDLsT8ak)|[✅](https://drive.google.com/open?id=1Sz-kUkiWAoQd6EHcUsFCtKX4y56np2DWs5Zl4GiYNmc)|[✅](https://about.gitlab.com/handbook/finance/accounting/#access-management-in-netsuite)|
|14|Record to Report|Chart of Accounts|[✅](https://drive.google.com/open?id=1lZV_jJ-5Joh6ujwuckGKwSasU5sV3cYHqbtjMh0OQHk)|[✅](https://drive.google.com/open?id=1AKTj-eaueuGZ81WzN0OrFioxVf7McXTDEo6gcYB_21I)|[✅](https://about.gitlab.com/handbook/finance/accounting/#creation-of-chart-of-accounts-and-gl-accounts)|
|15|Record to Report|Journal entries|[[✅](https://drive.google.com/open?id=1qrre9oXEpP_wuMtuGcRQA0Q-wwEGIBrdAxRLWXR3Fh8)|[✅](https://drive.google.com/open?id=1R340OKcZ-tV-f8aMUID8tEGjdWEoXuwOIjcOSe6ZKMg)|[✅](https://about.gitlab.com/handbook/finance/accounting/#recording-of-journal-entries)|
|16|Record to Report|Financial Planning and Analysis|[✅](https://drive.google.com/open?id=1eyJiYwwTs0tGYCavLL36HeLkwnSRmg2yoHpDQRy38yw)|[✅](https://drive.google.com/open?id=1cYXN5D50XMCdsdtapz8zV8XrdJ6NrTCRb6jys27IoaU)|[✅](https://about.gitlab.com/handbook/finance/accounting/#financial-planning-and-analysis-fpa)|
|17|Record to Report|Reconciliations|[[✅](https://drive.google.com/open?id=1PQneB_WEZuV995adkSmYvphvG_eOCcLJhPHcUHH7mCk)|[✅](https://drive.google.com/open?id=1VMkBDniBSu-_bWSG3VWBmBz03lY_eFsNe0zfkCWg2AI)|[✅](https://about.gitlab.com/handbook/finance/accounting/#balance-sheet-reconciliation)|
|18|Record to Report|Period End closure|[✅](https://drive.google.com/open?id=1wRdMtV9d_YWW1AD-2qPtfVHm0c2Pv6-58t4XbvxnY8Y)|[✅](https://drive.google.com/open?id=1etjKLOY3OmI0hgHPWi3p86HyZtl0fhP_8C2lG0Rh5OY)|[✅](https://about.gitlab.com/handbook/finance/accounting/#period-end-closure-and-reporting)|
|19|Record to Report|Treasury|✅|[✅](https://drive.google.com/open?id=1vCFjZIuJqnr6CR5sUbpuHzH9WYYv3O2AFN5tmQ4FB5k)|[✅](https://about.gitlab.com/handbook/finance/accounting/#policy-on-treasury-activities)|
|20|Record to Report|Financial Reporting|[✅](https://drive.google.com/open?id=1NMO82rsJD2cAYHl7uROXZtW_45w4J6QlqHQGzgnhSnU)|[✅](https://drive.google.com/open?id=1LkPugj0GABQlu1Rx1iaeKB6tmSTUVsvSjh44-H9dITI)|[✅](https://about.gitlab.com/handbook/finance/accounting/#reporting-1)|
|21|Regulatory|Sales Tax|[✅](https://drive.google.com/open?id=1dvGeHcL7WVF9qqmnpsRQ16Oz07_4JNRGQ0sdAd_z6Lo)|[✅](https://drive.google.com/open?id=1hWrxQb6d0QwdTCh-mGUiST0OEmsfM3G3UaQ5hs51E1Q)|[✅](https://about.gitlab.com/handbook/finance/accounting/#sales-tax)|
|22|Regulatory|Wage Tax|[✅](https://drive.google.com/open?id=1SMise3dKKVMHkZC0iP_gRSka3i1xL-7Y2P7uEEXB_2Q)|[✅](https://drive.google.com/open?id=1WwxG7eJ_akSsFpOvXnWFNOeONmWuN_cm8yH3D9FiKj8)|[✅](https://about.gitlab.com/handbook/finance/accounting/#wage-tax)|
|23|Regulatory|Corporate Income Tax|[✅](https://drive.google.com/open?id=1lgEWv0AxTzepqz2UmGr3uV-w_T5dCo6A2btJfzunFd8)|[✅](https://drive.google.com/open?id=18mF9M6rdVzAs64Of3kaHPB8t7glyW9l1xWA_rt10OdA)|[✅](https://about.gitlab.com/handbook/finance/accounting/#corporate-income-tax)|
|24|Hire to Retire|Recruitment|[✅](https://drive.google.com/open?id=1oS-S9YY-60cqntwxWuL3PY2tRfhyzHL0IM59pgHv86k)|[✅](https://drive.google.com/open?id=1K9JLOxuEBkvFcnstJwVAk6mgOD-0bqasQuywXeY2CPk)|[✅](https://about.gitlab.com/handbook/finance/accounting/#recruitment)|
|25|Hire to Retire|Employee Master Creation and Updates|[✅](https://drive.google.com/open?id=1JxP1nloc1lWk7lbu-xZlvn27y4kRyg4UVLuyyyxzCkw)|[✅](https://drive.google.com/open?id=1s_SiTc1ch85n_RaAeaTsgf88R839c6mAdH1kbiOZEoU)|[✅](https://about.gitlab.com/handbook/finance/accounting/#employee-master-creation-and-updates)|
|26|Hire to Retire|Payroll Processing for US|[✅](https://drive.google.com/open?id=1a1Q6ufhL7cw_RXiil6jb7E5JDkUNFQEfvfIw4OfZcM4)|[✅](https://drive.google.com/open?id=1Obzjm7etSzoDsn99qoAJYhKloxpRRFgcvaKlsPLjCRw)|[✅](https://about.gitlab.com/handbook/finance/accounting/#payroll-processing-for-us)|
|27|Hire to Retire|Payroll Processing for Non-US|[✅](https://drive.google.com/open?id=1NGva8C0DODnOPbbOWyKNnp8stMSI1Fhmc2_XPo7C-JU)|[✅](https://drive.google.com/open?id=1GR9jrvbcCI1P_fkItaS_vqIzhv-X8mLICdy5kt0qZwA)|[✅](https://about.gitlab.com/handbook/finance/accounting/#payroll-processing-for-non-us)|
|28|Hire to Retire|Leave Management for Payroll Processing|[✅](https://drive.google.com/open?id=11MfgPJVTUOuhai9-RbPfoIHkdIFdytYB6gwV5ig0rsE)|[✅](https://drive.google.com/open?id=1_7QuIqDeNyuXIVm0QzD73K6wpw9GLOE8i2oVJMPHBtY)|[✅](https://about.gitlab.com/handbook/finance/accounting/#leave-management-for-payroll-processing)|
|29|Hire to Retire|Employee Exits|[✅](https://drive.google.com/open?id=1kcL4MtHgb1v8s8U6B12cqpJlJCdZF1r_xod79qgIlQE)|[✅](https://drive.google.com/open?id=17hB3DJIprhJu-lNuD-6neNNAlr8tV1tPRBAxxlC_lLQ)|[✅](https://about.gitlab.com/handbook/finance/accounting/#clearance--exit-procedure)|
|30|Procure to Pay|Purchase Requisition|[⏰](https://docs.google.com/document/d/1VljaWnIbf3m8YZiG2jLt3eFy4m0i3iPRBqwziKH-FUA/edit#heading=h.tmopv7pxe42c)|⏰|⏰|
|31|Procure to Pay|Vendor Master Management|[⏰](https://docs.google.com/document/d/1VljaWnIbf3m8YZiG2jLt3eFy4m0i3iPRBqwziKH-FUA/edit#heading=h.bh5mxrwjanj)|⏰|⏰|
|32|Procure to Pay|Invoice Processing|[⏰](https://docs.google.com/document/d/1VljaWnIbf3m8YZiG2jLt3eFy4m0i3iPRBqwziKH-FUA/edit#bookmark=id.45j53l9eak1)|⏰|⏰|
|33|Procure to Pay|Payment Processing|[⏰](https://docs.google.com/document/d/1VljaWnIbf3m8YZiG2jLt3eFy4m0i3iPRBqwziKH-FUA/edit#heading=h.z6v1nfqtxidq)|⏰|⏰|
|34|Procure to Pay|Accounting|[⏰](https://docs.google.com/document/d/1VljaWnIbf3m8YZiG2jLt3eFy4m0i3iPRBqwziKH-FUA/edit#bookmark=id.qaqiu6cjz8ok)|⏰|⏰|
|35|Procure to Pay|Employee Travel|[⏰](https://docs.google.com/document/d/1VljaWnIbf3m8YZiG2jLt3eFy4m0i3iPRBqwziKH-FUA/edit#heading=h.91b68obqggn)|⏰|⏰|
**`2. Entity Level Controls`**
|**Control#**|**Process Name**|**RCM Link**|**Process Owner Sign-off**|**Handbook Link**
|:---|:---|:---|:---|:---
|ELC.C.01|Integrity and ethical values|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/867)|[✅](https://about.gitlab.com/handbook/people-operations/code-of-conduct/)
|ELC.C.02|Integrity and ethical values|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/868)|[✅](https://about.gitlab.com/handbook/people-operations/code-of-conduct/)
|ELC.C.03|Organisational structure|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/869 )|[Org Chart✅](https://about.gitlab.com/handbook/hiring/charts/), [Job Family✅](https://about.gitlab.com/handbook/hiring/job-families/), [Master Job Family✅](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master/source/job-families)
|ELC.C.04|Organisational structure|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/870 )|[✅](https://about.gitlab.com/handbook/finance/authorization-matrix/)
|ELC.C.05|Board of Directors & Audit Committee|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/871)|[✅](https://about.gitlab.com/handbook/board-meetings/)
|ELC.C.06|Board of Directors & Audit Committee|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/872)|[✅](https://about.gitlab.com/handbook/board-meetings/#audit-committee-charter)
|ELC.C.07|Board of Directors & Audit Committee|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/873)|[✅](https://about.gitlab.com/handbook/board-meetings/)
|ELC.C.08|Entity-wide objectives|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/889)|[Organization Strategy✅](https://about.gitlab.com/company/strategy/#mission),[KPI Index✅](https://about.gitlab.com/handbook/business-ops/data-team/metrics/)
|ELC.C.09|Risk Assessment|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/890)|[✅](https://about.gitlab.com/handbook/board-meetings/)
|ELC.C.10|Risk Assessment|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/891)|⏰
|ELC.C.11|Risk Assessment|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[⏰](https://gitlab.com/gitlab-com/finance/issues/893)|[✅](https://about.gitlab.com/handbook/finance/accounting/)
|ELC.C.12|Risk Assessment|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/892)|[✅](https://about.gitlab.com/handbook/tax/)
|ELC.C.13|Monitoring|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/894)|[✅](https://about.gitlab.com/handbook/board-meetings/)
|ELC.C.14|Monitoring|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/895)|[✅](https://about.gitlab.com/handbook/engineering/security/#sts=Information%20Security%20Policies )
|ELC.C.15|Monitoring|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/896)|[✅](https://about.gitlab.com/handbook/engineering/development/enablement/geo/)
|ELC.C.16|Risk Assessment|[✅](https://docs.google.com/spreadsheets/d/1O38zpJZfJjiA5WgFdnvuGltfosDlpHJdza4YqA-DK8c/edit?usp=sharing)|[✅](https://gitlab.com/gitlab-com/finance/issues/981)|[✅](https://about.gitlab.com/handbook/people-operations/code-of-conduct/)
**`3. Information Technology General Controls`**
|**Control#**|**Control Family**|**Control Short Name**|**Handbook link**|
| :--- |:---|:---|:---|
|BC.1.01|Business Continuity|Business Continuity Plan|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/BC.1.01_business_continuity_plan.html)
|BC.1.02|Business Continuity|Business Continuity Plan: Roles and Responsibilities|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/BC.1.02_business_continuity_roles_responsibilities.html#bc102---business-continuity-plan-roles-and-responsibilities)
|BC.1.03|Business Continuity|Continuity Testing|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/BC.1.03_continuity_testing.html#bc103---continuity-testing)
|BC.1.04|Business Continuity|Business Impact Analysis|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/BC.1.04_business_impact_analysis.html#bc104---business-impact-analysis)
|BU.1.01|Backup Management|Backup Configuration|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/BU.1.01_backup_configuration.html#bu101---backup-configuration)
|BU.1.02|Backup Management|Resilience Testing|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/BU.1.02_resilience_testing.html#bu102---resilience-testing)
|BU.1.03|Backup Management|Alternate Storage|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/BU.1.03_alternate_storage.html#bu103---backup-management-alternate-storage)
|CM.1.01|Change Management|Change Management Workflow|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/CM.1.01_change_management_workflow.html#cm101---change-management-workflow)
|CM.1.02|Change Management|Change Approval|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/CM.1.02_change_approval.html#cm102---change-approval)
|CM.2.01|Change Management|Segregation of Duties|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/CM.2.01_segregation_of_duties.html)
|CFG.1.01|Configuration Management|Baseline Configuration Standard|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/CFG.1.01_baseline_configuration_standard.html#cfg101---baseline-configuration-standard)
|IAM.1.01|Identity and Access Management|Logical Access Provisioning|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.1.01_logical_access_provisioning.html#iam101---logical-access-provisioning)
|IAM.1.02|Identity and Access Management|Logical Access De-provisioning|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.1.02_logical_access_deprovisioning.html#iam102---logical-access-de-provisioning)
|IAM.1.04|Identity and Access Management|Logical Access Review|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.1.04_logical_access_review.html#iam104---logical-access-review)
|IAM.1.05|Identity and Access Management|Role Change: Access De- provisioning|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.1.05_role_change_access_deprovisioning.html#iam105---transfers-access-de-provisioning)
|IAM.1.06|Identity and Access Management|Shared Logical Accounts|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.1.06_shared_logical_accounts.html#iam106---shared-logical-accounts)
|IAM.2.01|Identity and Access Management|Unique Identifiers|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.2.01_unique_identifiers.html#iam201---unique-identifiers)
|IAM.2.02|Identity and Access Management|Password Authentication|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.2.02_password_authentication.html#iam202---password-authentication)
|IAM.2.03|Identity and Access Management|Multifactor Authentication|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.2.03_multifactor_authentication.html#iam203---multi-factor-authentication)
|IAM.2.04|Identity and Access Management|Authentication Credential Maintenance|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.2.04_authentication_credential_maintenance.html#iam204---authentication-credential-maintenance)
|IAM.2.08|Identity and Access Management|Account Lockout|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.2.08_account_lockout.html#iam208---account-lockout)
|IAM.3.02|Identity and Access Management|Source Code Security|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.3.02_source_code_security.html#iam302---source-code-security)
|IAM.3.03|Identity and Access Management|Service Account Restrictions|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.3.03_service_account_restriction.html#iam303---service-account-restrictions)
|IAM.4.01|Identity and Access Management|Remote Connections|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.4.01_remote_connections.html#iam401---remote-connections)
|IAM.4.03|Identity and Access Management|Remote Maintenance: Authentication Sessions|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IAM.4.03_remote_maintenance_authentication_sessions.html#iam403---remote-maintenance-authentication-sessions)
|IR.1.01|Incident Response|Incident Response Plan|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/IR.1.01_incident_response_plan.html#ir101---incident-response-plan)
|NO.1.01|Network Operations|Network Policy Enforcement Points|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/NO.1.01_network_policy_enforcement_points.html)
|NO.2.01|Network Operations|Network Segmentation|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/NO.2.01_network_segmentation.html#no201---network-segmentation)
|RM.1.01|Risk Management|Risk Assessment|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/RM.1.01_risk_assessment.html#rm101---risk-assessment)
|RM.1.02|Risk Management|Continuous Monitoring|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/RM.1.02_continuous_monitoring.html)
|SLC.1.02|Service Lifecycle|Source Code Management|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/SLC.1.02_source_code_management.html#slc102---source-code-management)
|SYS.1.01|Systems Monitoring|Audit Logging|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/SYS.1.01_audit_logging.html#sys101---audit-logging)
|SYS.1.02|Systems Monitoring|Secure Audit Logging|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/SYS.1.02_secure_audit_logging.html#sys102---secure-audit-logging)
|SYS.1.05|Systems Monitoring|Audit Logging: Service Provider Logging Requirements|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/SYS.1.05_audit_logging_service_provider.html#sys105---audit-logging-service-provider-logging-requirements)
|SYS.1.07|Systems Monitoring|Audit Log Capacity and Retention|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/SYS.1.07_audit_log_capacity_retention.html#sys107---audit-log-capacity-and-retention)
|TPM.1.01|Third Party Management|Third Party Assurance Review|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/TPM.1.01_third_party_assurance_review.html#tpm101---third-party-assurance-review)
|VUL.3.01|Vulnerability Management|Infrastructure Patch Management|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/VUL.3.01_infrastructure_patch_management.html#vul301---infrastructure-patch-management)
|DM.4.01|Data Management|Encryption of Data in Transit|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/DM.4.01_encryption_of_data_in_transit.html#dm401---encryption-of-data-in-transit)
|DM.4.02|Data Management|Encryption of Data at Rest|[✅](https://about.gitlab.com/handbook/engineering/security/guidance/DM.4.02_encryption_of_data_at_rest.html#dm402---encryption-of-data-at-rest))
**`4. Risk Assessment and Scoping`**
**`5. Business Process Risk Control Matrix`**
|**Control#**|**Business Process Name**|**Process Name**|
|:---|:---|:---|
|QTC.C.01|Quote to Cash|Customer account management (Sales operations team assisted sale)|
|QTC.C.02|Quote to Cash|Customer account management (Online sale)|
|QTC.C.03|Quote to Cash|Price master management for products|
|QTC.C.04|Quote to Cash|Price master management for products|
|QTC.C.05|Quote to Cash|Quote creation for services (Sales operations team assisted sale)|
|QTC.C.06|Quote to Cash|Quote creation for services (Sales operations team assisted sale)|
|QTC.C.07|Quote to Cash|Quote creation for products (Sales operations team assisted sale)|
|QTC.C.08|Quote to Cash|Quote creation for products and services (Sales operations team assisted sale)|
|QTC.C.09|Quote to Cash|Reseller management|
|QTC.C.10|Quote to Cash|Invoicing for products and services (Sales operations team assisted sale)|
|QTC.C.11|Quote to Cash|Invoicing for products and services (Sales operations team assisted sale)|
|QTC.C.12|Quote to Cash|Invoicing for products and services (Sales operations team assisted sale)|
|QTC.C.13|Quote to Cash|Invoicing for products (Online sale)|
|QTC.C.14|Quote to Cash|Invoicing for products (Renewals)|
|QTC.C.15|Quote to Cash|Invoicing for products (Online and Sales operations team assisted sale)|
|QTC.C.16|Quote to Cash|Invoice cancellations and refunds for products and services (Sales operations team assisted sale)|
|QTC.C.17|Quote to Cash|Invoice cancellations and refunds for products and services (Sales operations team assisted sale)|
|QTC.C.18|Quote to Cash|Accounting for transactions (recorded in Zuora) in Net Suite|
|QTC.C.19|Quote to Cash|Income from sale of merchandise|
|QTC.C.20|Quote to Cash|Income from GCP referral|
|QTC.C.21|Quote to Cash|Accounts receivable|
|QTC.C.22|Quote to Cash|Accounts receivable|
|QTC.C.23|Quote to Cash|Accounts receivable|
|QTC.C.24|Quote to Cash|Accounts receivable|
|QTC.C.25|Quote to Cash|Accounts receivable|
|QTC.C.26|Quote to Cash|Accounts receivable|
|QTC.C.27|Quote to Cash|Accounts receivable|
|QTC.C.28|Quote to Cash|Accounts receivable|
|QTC.C.29|Quote to Cash|Commissions to sales team|
|QTC.C.30|Quote to Cash|Commissions to sales team|
|QTC.C.31|Quote to Cash|Commissions to sales team|
|FR.C.01|Record to Report|Chart of accounts and GL accounts|
|FR.C.02|Record to Report|Chart of accounts and GL accounts|
|FR.C.03|Record to Report|Chart of accounts and GL accounts|
|FR.C.04|Record to Report|Chart of accounts and GL accounts|
|FR.C.05|Record to Report|NetSuite User Access Management|
|FR.C.06|Record to Report|Accruals|
|FR.C.07|Record to Report|Provisioning|
|FR.C.08|Record to Report|Provisioning|
|FR.C.09|Record to Report|Taxation|
|FR.C.10|Record to Report|Financial Closure - Posting from sub ledger to General Ledger|
|FR.C.11|Record to Report|Financial Closure - Posting from sub ledger to General Ledger|
|FR.C.12|Record to Report|Financial Closure - Close Process|
|FR.C.13|Record to Report|Financial Closure - Close Process|
|FR.C.14|Record to Report|Financial Closure - Close Process|
|FR.C.15|Record to Report|Financial Closure - Close Process|
|FR.C.16|Record to Report|Financial Closure - Close Process|
|FR.C.17|Record to Report|Financial Closure - Close Process|
|FR.C.18|Record to Report|Accounting Policies.|
|FR.C.19|Record to Report|Accounting Policies.|
|FR.C.20|Record to Report|Accounting Policies.|
|FR.C.21|Record to Report|Consolidation|
|FR.C.22|Record to Report|Reporting|
|FR.C.23|Record to Report|Reporting|
|FR.C.24|Record to Report|Reporting|
|FR.C.25|Record to Report|Reporting|
|FR.C.26|Record to Report|Reporting|
|FR.C.27|Record to Report|Treasury|
|FR.C.28|Record to Report|Treasury|
|FR.C.29|Record to Report|Treasury|
|FR.C.30|Record to Report|Treasury|
|FR.C.31|Record to Report|Treasury|
|HTR.C..01|Hire To Retire|Hiring|
|HTR.C..02|Hire To Retire|Recruitment|
|HTR.C..03|Hire To Retire|Recruitment|
|HTR.C..04|Hire To Retire|Employee Masters|
|HTR.C.05|Hire To Retire|Employee Masters|
|HTR.C..06|Hire To Retire|Employee Masters|
|HTR.C..07|Hire To Retire|Employee Masters|
|HTR.C..08|Hire To Retire|Payroll Processing - Leave Management|
|HTR.C..09|Hire To Retire|Payroll Processing & Disbursement- Contract Labor|
|HTR.C..10|Hire To Retire|Payroll Processing & Disbursement- Employees|
|HTR.C..11|Hire To Retire|Payroll Processing & Disbursement- Employees|
|HTR.C..12|Hire To Retire|Payroll Processing & Disbursement|
|HTR.C.13|Hire To Retire|Payroll Processing & Disbursement|
|HTR.C..14|Hire To Retire|Payroll Accounting|
|HTR.C..15|Hire To Retire|Payroll Accounting|
|HTR.C..16|Hire To Retire|Exit|
|REG.C.01|Regulatory|Sales Tax/ Value Added Tax/ Goods and Service Tax|
|REG.C.02|Regulatory|Sales Tax/ Value Added Tax/ Goods and Service Tax|
|REG.C.03|Regulatory|Sales Tax/ Value Added Tax/ Goods and Service Tax|
|REG.C.04|Regulatory|Sales Tax/ Value Added Tax/ Goods and Service Tax|
|REG.C.05|Regulatory|Sales Tax/ Value Added Tax/ Goods and Service Tax|
|REG.C.06|Regulatory|Sales Tax/ Value Added Tax/ Goods and Service Tax|
|REG.C.07|Regulatory|Corporate Income tax|
|REG.C.08|Regulatory|Corporate Income tax|
|REG.C.09|Regulatory|Wage tax|
|REG.C.10|Regulatory|Wage tax|
|REG.C.11|Regulatory|Wage tax|
|REG.C.12|Regulatory|Wage tax|
|REG.C.13|Regulatory|Wage tax|
|REG.C.14|Regulatory|Wage tax|
|REG.C.15|Regulatory|Wage tax|
|REG.C.16|Regulatory|Wage tax|
|REG.C.17|Regulatory|Wage tax|
|P2P.G.01|Procure to Pay||
|P2P.G.02|Procure to Pay|Employee reimbursements|
|P2P.G.03|Procure to Pay|Order Management|
|P2P.G.04|Procure to Pay|Employee reimbursements|
|P2P.G.05|Procure to Pay|Invoice Accounting|
|P2P.G.06|Procure to Pay|Invoice Accounting|
|P2P.G.07|Procure to Pay|Order Management|
|P2P.G.08|Procure to Pay|Requirement Identification|
|P2P.G.09|Procure to Pay|Vendor Management|
|Disclosure Control|Record to Report|Identification and reporting of disclosable information|
**`6. Disclosure Committee`**
| Disclosure Committee Charter Drafted | Charter Approved |
|---|---|
| [✅](https://about.gitlab.com/handbook/internal-audit/sarbanes-oxley/#disclosure-committee-charter-effective-2019-10-17) |[✅](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/32646)|
**`7. Disclosure Controls Policies and Procedures`**
| Disclosure Controls Policies and Procedures Drafted | Policy Approved |
|---|---|
| [✅](https://about.gitlab.com/handbook/internal-audit/sarbanes-oxley/#gitlabs-disclosure-controls-policy-and-procedures) |[✅](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/32806/diffs)|
**`8. Sec 302 Certification Process`**
# Sarbanes-Oxley Roles and Responsibilities
**Process/ Control Owner**
The process/control owner has a primary responsibility of updating control descriptions in the handbook for those controls in which they have been identified as the control owner. In this role, the process/control owner will update the control descriptions for any assigned controls any time there is a change in a process or control that requires a change in the information. Some process/control owners will also complete a quarterly change control questionnaire that will alert the SOX project management office (PMO) of any changes that have occurred throughout the last three months. The roles and responsibilities of the process/control owner include the following:
* Confirm control description for controls that are assigned to you.
* Update control information in the handbook when process changes occur. This includes the control description, control frequency, control type, control owner, etc.
* Update handbook and provide edits to the SOX PMO for review.
* Communicate process changes and control changes to the SOX PMO within 30 days of the change.
* Quarterly, some process owners are required to complete a series of change control questions as part of their regular financial certification process. These questions are designed to alert management of any process changes that have occurred during the last three months.
* Make yourself available to speak with the SOX PMO upon their request for walkthroughs, sign-offs , testing and for discussion of test results .
* Provide test evidence to the SOX PMO upon request.
* Remediate control deficiencies.
**SOX Program Management Office ([PMO](https://en.wikipedia.org/wiki/Project_management_office))**
The SOX PMO , division of internal audit department has the primary responsibility of managing GitLab’s Sarbanes-Oxley (SOX) compliance program. In this role, the PMO will work under the direction of the Principal Accounting Officer to ensure adequate coverage for SOX compliance.The roles and responsibilities of the PMO include the following:
* Determine the project scope at the beginning of each reporting year and update quarterly.
* Build the internal control assessment plan for the upcoming year and include timelines.
* Communicate project timelines to the process/control owners to ensure the completion of project objectives.
* Schedule process walk-throughs for each process with process/control owners.
* Review all current and prior-year control deficiencies in order to determine the remediation status during a walk-through
* Update process maps based on information gathered by process/control owners.
* Develop programs to evaluate and measure entity-level controls.
* Perform general IT controls testing.
* Create templates for documentation and perform testing of controls.
* Identify, confirm and report testing exceptions with management
* Prepare control deficiency reports and follow up on remediation efforts.
* Report updates in the key stakeholders meeting on the status of outstanding items and deficiencies to ensure progress in remediation efforts.
* Meet with external auditors as necessary to provide status updates and remediation efforts of ongoing work.
* Practice professional skepticism when reviewing documents. Anticipate the external auditor’s questions when reviewing control descriptions and documentation.
The below [RACI ](https://en.m.wikipedia.org/wiki/Responsibility_assignment_matrix)table is used for clarifying, defining roles and responsibilities in cross-functional or departmental projects and processes.
| **#** | **Activity** |**Responsibility (R)**|**Accountability (A)** |**Consulted (C)**|**Informed (I)**|
| ------ | ------ |------ |------ |------ |------ |
| 1| SOX Scoping and Risk Assessment |PMO|PAO |PO|KSH|
| 2| RCM Preparation and Reviews |PMO|PAO |PO|KSH|
| 3| RCM Confirmation and Sign-off |PO|PAO |PMO|CFO|
| 4| Control Change Updates |PMO|PAO |PO|PO|
| 5| Remediation of Gaps |PO|PAO |PMO|CFO|
|6| Process Flowcharts |PMO|PAO |PO|PO|
| 7| SOX 404 Management Testing |PMO|PAO |PO|CFO, KSH|
| 8| SOX 302 Certification |PMO|CEO, CFO|PAO|KSH|
| 9| SOX 404 Certification |PMO|CEO, CFO|PAO|KSH|
| 10| 10-K filing |PAO|CEO, CFO|PAO|KSH|
| 11 |10-Q filing |PAO|CEO, CFO|PMO|KSH|
* CEO - Chief Executive Officer
* CFO - Chief Financial Officer
* PAO - Principal Accounting Officer
* KSH - Key Stakeholders
* PMO - Internal Audit, SOX PMO
* PO - Process Owner
# Sarbanes-Oxley Section 404 Management Testing Plan
**Objective**
The objective of this document is to summarize management’s approach to plan, organize, execute, document and support its assessment of the effectiveness of GitLab and its subsidiaries’ internal control over financial reporting. Specifically, this document will address the following:
* Nature, extent and timing of evaluation procedures
* Techniques used to evaluate the design and operating effectiveness of controls
* Documentation requirements with respect to the evaluation
* Frequency of evaluation
* Reporting and tracking evaluation results
* Reporting and tracking of the evaluation status
**Management's Responsibilities**
Under the SEC’s rules implementing the requirement of Section 404 of the Sarbanes Oxley Act of 2002, each annual report must include management’s report on internal control over financial reporting that contains the following elements:
* A statement of management responsibility for establishing and maintaining adequate internal control over financial reporting for the company;
* A statement identifying the framework used by management to conduct the required evaluation of the effectiveness of the company’s internal control over financial reporting;
* Management’s assessment of the effectiveness of the company’s internal control over financial reporting as of the end of GitLab’s most recent fiscal year, including a statement as to whether or not the company’s internal control over financial reporting is effective. The assessment must include disclosure of any “material weaknesses” in the company’s internal control over financial reporting identified by management. Management is not permitted to conclude that the company’s internal control over financial reporting is effective if there are one or more material weaknesses in the company’s internal control over financial reporting; and
* A statement that the registered public accounting firm that audited the financial statements included in the annual report has issued an attestation report on management’s assessment of GitLab’s internal control over financial reporting.
The remainder of this document summarizes the scope and approach of management’s assessment of the effectiveness of the company’s internal control over financial reporting (third bullet above).
**COSO Framework**
GitLab has adopted the COSO framework as the criteria for evaluating the effectiveness of the company’s internal control over financial reporting. The COSO framework includes the following components:
* Control Environment
* Risk Assessment
* Control Activities
* Information and Communication
* Monitoring
Management’s overall assessment must take into consideration all five components of the COSO framework. The decision as to whether an organization’s control structure is operating satisfactorily or not is ultimately one of judgment, dependent upon the relative significance placed on any given component of the control framework.
**Project Team and Timing**
Senior Internal Audit Manager has been identified as the project leader and will assume the responsibility for providing the overall direction to the project teams and for communicating the project status to management. An in-house internal audit team and a third party consulting firm, as required, will assist the project leader in this effort.
Significant milestones relating to the management evaluation of internal controls over financial reporting and estimated timing is defined [here](/handbook/internal-audit/sarbanes-oxley/#sox-compliance-roadmap-for-gitlab).
As testing begins, a detailed timeline for completing the testing of internal controls by process will be prepared. Project leader will report project status and results to the management on a monthly basis.
**Approach to evaluation**
This document lays the framework for testing the effectiveness of controls over all relevant assertions related to all significant accounts and disclosures in the financial statements.
Controls that are significant generally include:
* Controls over initiating, authorizing, recording, processing, and reporting significant accounts and disclosures and related assertions embodied in the financial statements.
* Controls over the selection and application of accounting policies that are in conformity with generally accepted accounting principles.
* Antifraud programs and controls
* Controls, including information technology general controls, on which other significant controls are dependent.
* Controls over significant non-routine and nonsystematic transactions, such as accounts involving judgments and estimates.
* Company level controls, including:
- The control environment and
- Controls over the period-end financial reporting process, including controls over procedures used to enter transaction totals into the general ledger; to initiate, authorize, record and process journal entries in the general ledger; and to record recurring and nonrecurring adjustments to the financial statements (for example, consolidating adjustments, report combinations, and reclassifications).
* To determine the controls to be included in the testing plan, management will also consider the following matters:
* The nature of the control (e.g., its subjectivity).
* The likelihood of material misstatement that would result from failure of the control.
* The risk that the control might not be operating effectively, which might be assessed by considering the following:
- Whether there have been changes in the volume or nature of transactions that might adversely affect control design or operating effectiveness.
- Whether there have been changes in the design of controls.
- The degree to which the control relies on the effectiveness of other controls.
- Whether there have been changes in key personnel who perform the control or monitor its performance.
- Whether the control relies on performance by an individual or is automated.
- The complexity of the control.
* Anti-fraud controls, general controls, safeguarding controls, authorization controls and the maintenance of records.
* The significance of the control in achieving the objectives of the control criteria and whether more than one control achieves a particular objective.
Management’s approach to its assessment of the effectiveness of the company’s internal control over financial reporting is organized in two phases: (1) assessing the entity-wide control framework and (2) assessing process level controls.
**Assessing the entity-wide control framework**
Management will document the company’s existing entity-wide/corporate control framework and identify potential gaps between the company’s framework and the COSO control framework. The documentation and analysis of the framework will be focused on the entity-wide/corporate internal control over financial reporting, particularly relating to the control environment, risk assessment and monitoring components of COSO. In order to apply and/or assess the components of COSO as they relate to internal control over financial reporting, management must gain an understanding as to the criteria for rating them. In other words, how does the company determine if the control environment, risk assessment process, etc. are satisfactory? Included in Appendix A are some of the key control factors of each of the five COSO components relating to internal control over financial reporting.
**Assessing process level controls**
Over the past few months, SOX PMO have prepared risk and control matrices in consultation with process owners. In addition to documenting GitLab’s business processes, these risk and control matrices identify the controls over relevant assertions related to all significant accounts and disclosures in the financial statements. These risk and control matrices will be the basis for assessing process level controls. The matrices are to be reviewed and approved by the business process owners and the project leader prior to executing control assessment procedures.
Assessing process level controls will include an evaluation of control design and an evaluation of control effectiveness.
**Evaluating design effectiveness of controls**
Design effectiveness refers to whether a control is suitably designed to prevent or detect material misstatements in financial statements. It involves consideration of the financial reporting objectives that the control is meant to achieve and whether it will achieve them. When evaluating control design, management should consider the following:
* Whether the control achieves the financial reporting objective.
* How the control is performed.
* The frequency with which the control is performed.
* The competence and experience of individuals involved in the process and executing the control.
* The nature and size of misstatement that the control is likely to detect.
* Follow-up activity on exceptions identified by the control.
Consideration should be given to each significant control in a group of controls that function together to achieve a control objective. While it is expected that the majority of controls identified will be tested, insignificant controls do not need to be tested if there is another control that will adequately cover the objective.
It is the responsibility of line management to evaluate the design effectiveness of controls in their respective area. Line management will use the recently completed process, risk and control documentation to identify whether there are financial reporting risks not mitigated by controls, e.g., are the controls designed effectively. The risk and control matrices, together with a listing of control gaps or deficiencies, will serve as evidence of this evaluation. If the design of a particular control is deemed to be inadequate or a control gap is identified, business process owners will implement additional controls or changes in the design of existing controls. To maintain management’s evaluation of design effectiveness current, line management will review process, risk and control documentation at quarterly intervals to identify any new or changed risks and highlight the relevant controls that have been implemented to mitigate these risks.
**Evaluating operating effectiveness of controls**
Operating effectiveness refers to whether the control is functioning as designed. During the evaluation of operating effectiveness, management gathers evidence regarding how the control was applied, the consistency with which it was applied, and by whom it was applied.
SOX PMO will execute testing procedures, approved by management, to support management’s evaluation of operating effectiveness of controls for in-scope routine processes.
In developing the plan for evaluating operating effectiveness of controls, management will consider the following:
* Selection of Test Type and Control Categories
* Extent of Testing (Sample Sizes)
* Timing of Testing
* Documentation of Test Results
Prior to performing test work on the operating effectiveness of internal control over financial reporting, audit programs will be prepared. The audit program will set out the nature, timing and extent of the procedures to be performed and will serve as a set of instructions to those performing the work. Audit programs will include:
* Description of the audit program objectives.
* A description and record of the nature, timing and extent of evaluation and other procedures performed to support the audit program objectives.
* An indication as to who performed the procedures and when they were performed.
* A conclusion as to whether the procedures performed accomplished the objectives of the audit program.
**Selection of Test Type and Control Categories**
There are a number of techniques that may be used to obtain evidence about the effectiveness of the operation of controls. These techniques include observation, inquiry, inspection and re-performance. There are additional techniques that, when combined with the previously listed techniques may be used to gain sufficient and appropriate evidence related to the operating effectiveness of a control. These techniques include knowledge assessment, corroborative inquiry and system query. See description of testing techniques included in Appendix B.
To determine the appropriate testing technique, it is first necessary to categorize controls into a control type. Controls can generally be categorized into the following:
* Authorization
* Exception/edit reports
* Interface/conversion controls
* Key performance indicators
* Management review
* Reconciliation
* Segregation of duties
* System access
* System configuration/account mapping controls.
Selection of an appropriate control category is an important step as the category selected is directly linked to the types of test procedures. General testing steps for determining control effectiveness for each control type are outlined in Appendix C. For controls not falling into the control categories listed above, testing procedures will be determined based on the distinct nature of the control.
**Extent of Testing (Sample Sizes)**
It is necessary to test controls to the extent deemed necessary for management to be satisfied that the results of the test provide conclusive evidence for management to support the assertion that the control is operating effectively. Once it is decided which technique or combination of techniques to use, the number of items to test in determining whether the control is operating effectively and consistently depends on how the control was applied, the consistency with which it was applied, and by whom the control was performed.
The first step in determining sample size is determining if the control is manual or automated (i.e., system controls). Manually applied controls are prone to random failures, whereas automated controls should be reliable and, as long as the computer systems are working effectively, will tend to operate consistently.
The nature of the control (i.e., manual or automated) will be documented in the risk and control matrices. The following baselines will be used in making sample size judgments for manual and automated controls:
When testing monitoring or manual controls, the sample size will depend on the frequency at which the control occurs. Testing standards are as follows:
| Frequency of Control | Baseline Sample Size |
| ------ | ------ |
| Annual | 1 |
| Semi-annual | 1 |
| Quarterly | 2 |
| Monthly | 3 |
| Fortnight | 5 |
| Weekly | 5 |
| Daily / Recurring (multiple times per day)| 25 |
In situations where an automated or IT control exists and is applied to every transaction, testing will generally be minimal as management will have tested general computer controls to be satisfied that they are functioning appropriately. Therefore, system query will often be the most appropriate testing technique. In this technique, one query as a test is appropriate for an IT system that would be expected to operate consistently in a well-controlled environment. A well-controlled environment is one where the specific configuration, interfaces and system access are appropriately designed and subject to appropriate change control procedures. Observation should also be made to ascertain whether there is any violation to the security access such as sharing of passwords.
Samples should be selected randomly to reflect an appropriate representation of the population. The specific sources and populations used for making sample selections will vary from control to control. Determining the appropriate source and population is a matter of judgment and should consider the following:
* Pervasiveness of the control and variety of instances in which the control is applied or by whom the control is applied.
* Changes in key personnel who perform the control or monitor its performance.
* Consistency with which the control is applied, i.e., sample sources and populations should cover an amount of time that will allow management to conclude on the consistency with which the control was applied.
* Quantitative measures for selecting high value items.
The above guidance on extent of testing applies in situations where there is a population to sample from. Controls may also exist where testing techniques and sample sizes may not be applicable. For example:
* In situations where the knowledge assessment technique is used, extent to testing should be sufficient to provide comfort regarding the knowledge of that one individual.
* In situations where corroborative inquiry is used, the extent of testing should be sufficient to confirm consistency in application of the control.
Rationale for determining sample selection sources and populations will be documented in the working papers, as appropriate.
**Timing of Testing**
Test of controls should be performed over a period of time that is adequate to determine whether, as of the date specified in the assertion, the controls necessary for achieving the objectives of the control criteria are operating effectively. The period of time over which tests of controls should be performed is a matter of management judgment.
If controls are to be tested over a period of time such as at an interim date using techniques other than knowledge assessment or corroborative inquiry (i.e., inspection, observation, re-performance), management should consider what additional evidence concerning the operation of the control should be obtained for the remaining period.
Evidence should be obtained about the nature and extent of any significant changes in internal control that occur subsequent to the previous or interim date through, for example, inquiry or observation. In addition, sufficient evidence should be obtained about the operating effectiveness of such controls since the previous or interim date, for example, by obtaining evidence about the operating effectiveness of the company’s monitoring of controls.
Prior to the date specified in the assertion, management may change the company’s controls to make them more effective or efficient, or to address control deficiencies. In these circumstances, controls that have been superseded may not need to be considered. For example, if management asserts that the new controls achieve the related objectives of the control criteria and have been in effect for a sufficient period and there is sufficient time to permit the testing of the new design and operating effectiveness, tests may not need to be performed on the design and operating effectiveness of the superseded controls, except to the extent of communicating identified significant deficiencies in controls that might have been identified in an interim period.
Management will prepare a detailed timeline for evaluation of control design and control effectiveness, as well as timelines to address control deficiencies and update control documentation.
**Documentation of Test Results**
In evaluating and developing the assessment of internal control over financial reporting, evidential matter needs to be maintained to provide reasonable support in the review of management’s assessment and attestation conducted by the independent auditor. This evidential matter must provide sufficient documentation to enable the external auditor to conclude that there is a reasonable basis for the assertion on internal control over financial reporting that will be made by management.
Working papers will be prepared and crossed referenced to enable reviewers and external auditors to easily locate the documentation that supports the conclusion reached on the assessment of the selected internal controls over financial reporting. Working papers will include sufficient documentation to re-perform control testing (i.e., copies of sample documents tested) and will include supporting documentation for all testing exceptions.
**Categorization and Escalation of Issues and Remediation**
When performing tests of operating effectiveness, management may find exceptions from prescribed control policies or procedures, as we do not expect controls to operate perfectly. In these instances, the nature and cause of the conditions must be investigated. Management is responsible for determining if a mitigating control compensates for the defective control and if that control is designed to achieve the same control objective. If the compensating control is appropriately designed, tests of operating effectiveness will then be performed on the compensating control.
When control testing exceptions are identified, the following steps will be taken:
* The exception will be recorded in a repository of findings. The repository of findings will include the testing observation, control theme, potential implications, short-term and long-term action plans, potential impact of the weakness and identification of mitigating controls. Maintenance of the repository will be the responsibility of the project leader.
* The exception will be brought to the attention of a “Resolution Team” which will include the process owner and appropriate management, including the project leader. The responsibility to determine whether a deficiency is a significant deficiency or a material weakness lies with management.
Deficiencies can range from inconsequential, to significant, to material weaknesses. In limited situations, there may be sufficient evidence to conclude that the error was an isolated incident. If this is the case, it may still be possible to conclude that the control is operating effectively. Management will assess whether deficiencies, either individually or in the aggregate, rise to the level of a significant deficiency or a material weakness. According to the [PCAOB](https://pcaobus.org/) Final Ruling, significant deficiencies and material weaknesses are defined as follows:
* **Significant deficiency**: A control deficiency, or combination of control deficiencies, that adversely affects the company’s ability to initiate, authorize, record, process and report external financial data reliably in accordance with generally accepted accounting principles such that there is more than a remote likelihood that a misstatement of the company’s annual or interim financial statements that is more than inconsequential will not be prevented or detected.
* **Material weakness**:A significant deficiency, or combination of significant deficiencies, that results in more than a remote likelihood that a material misstatement of the annual or interim financial statements will not be prevented or detected.
Deciding whether an internal control deficiency is a significant deficiency or material weakness requires both a detailed understanding by management of the relevant facts and circumstances, and a considerable amount of management judgment. Management will evaluate and formally document its assessment of the significance of a deficiency in internal control over financial reporting by determining the following:
* The likelihood that a deficiency, or combination of deficiencies, could result in a misstatement of an account balance or disclosure.
* The magnitude of potential misstatement resulting from the deficiency or deficiencies.
When corrective action is taken to remedy a control deficiency, the corrected control should be in place and operating for a sufficient period of time prior to the assertion date for management to evaluate the corrected control and conclude that the control is operating effectively as of the assertion date. In addition, management will allow sufficient time to test the operating effectiveness of the control. Management will provide a rationale as to why a significant deficiency was not corrected or did not preclude them from concluding that the internal controls over financial reporting were operating effectively.
**Appendix A: Evaluation of COSO Control Components**
`Control Environment`
The control environment sets the tone of an organization, influencing the control consciousness of its people. It is the foundation for all components of internal control, providing discipline and structure.
The control environment encompasses several control factors, including:
* Integrity and Ethical Values
* Commitment to Competence
* Board of Directors or Audit Committee
* Management’s Philosophy and Operating Style
* Organizational Structure
* Assignment of Authority and Responsibility
* Human Resource Policies and Procedures
These controls can be broken down as either hard controls (audit committee, organizational structure, assignment of authority and responsibility, human resources policies and procedures) or soft, cultural controls (integrity and ethics, commitment to competence, management operating style). Analysis of the control environment includes consideration as to whether the hard controls are functioning effectively and if there appears to be a breakdown in the soft controls.
Effectively controlled entities strive to have competent people, instill an enterprise-wide attitude of integrity and control consciousness, and set a positive “tone at the top.” They establish appropriate policies and procedures, often including a written code of conduct, which foster shared values and teamwork in pursuit of the entity’s objectives.
`Risk Assessment`
Every institution faces a variety of risks from external and internal sources that must be assessed. A precondition to risk assessment is establishment of objectives, linked at different levels and internally consistent. Risk assessment is the identification and analysis of relevant risks to achievement of the objectives, forming a basis for determining how the risks should be managed. Because economic, industry, regulatory, and operating conditions will continue to change, mechanisms are needed to identify and deal with the special risks associated with change.
According to COSO, effective risk assessment requires:
* Definition of established objectives at both the strategic (entity-wide) level and the process (activity) level. Objectives must be relevant, consistent, and compatible across levels.
* Identification of relevant internal and external risk factors that could impact achievement of the defined objectives.
* Mechanisms in place to continually re-assess risk and react to changing environments.
`Control Activities`
Control activities are the policies and procedures that help ensure management directives are carried out. They help ensure that necessary actions are taken to address risks to achievement of the entity’s objectives. Control activities occur throughout the organization, at all levels and in all functions.
Specific control activities and related control objectives should be documented. With respect to financial reporting, some generic control activities may include written policies and procedures, appropriate authorizations, adequate record keeping, management reviews, and asset safeguards. Control activities over financial reporting may also include or overlap with information system and operational controls. When evaluating control activities, management must consider:
* Appropriate policies and procedures existence and are consistently applied.
* Documented control activities are functioning as intended.
`Information and Communication`
Pertinent information should be identified, captured, processed, and communicated in a form and timeframe that enables the individuals to carry out their responsibilities. Information systems produce reports that contain operational, financial and compliance-related information and make it possible to run and control the business. They deal not only with internally generated data, but also information about external events, activities and conditions necessary for informed business decision-making and external reporting. Effective communication also must occur in a broader sense, flowing down, across and up the organization, as well as externally.
Management must consider the following control criteria for processing information:
* Information is relevant – internal and external information is obtained relative to established objectives.
* Information is provided in timely fashion to appropriate persons and in sufficient detail, such that they can carry out their responsibilities efficiently and effectively.
Communication of information is inherent in processing information; management must consider:
* Effective communication to employees of roles and control responsibilities.
* Established and effective channels of communication for employees to report suggested improvements or improprieties.
* Adequacy of communication across processes.
* Adequacy of communication to external parties such as customers or suppliers.
* Management’s responsiveness to information communicated from external and internal sources.
`Monitoring`
Internal control systems need to be monitored – a process that assesses the quality of the system’s performance over time. This is accomplished through ongoing monitoring activities, separate evaluations, or a combination of the two.
Monitoring occurs through management and supervisory personnel assessing the quality of internal control systems over the ordinary course of operations. In the evaluation of the monitoring component, management must consider the following criteria:
* Extent to which personnel obtain evidence as to the continuing effectiveness of internal control.
* Periodic comparison of accounting system information to physical assets.
* Management responsiveness to recommendations on strengthening internal controls.
* Extent to which information and communication provide feedback to management as to the continuing effectiveness of controls.
* Effectiveness of internal audit activities.
**Appendix B: Testing Techniques**
|` Testing Technique`| `Description`|
| ------ | ------ |
| Observation | Observe the performance of the control. |
| Inquiry| Ask a knowledgeable person for information about the operation of a control; evaluate and obtain evidence about the appropriateness of the follow-up actions.
Note that inquiry alone is not sufficient to provide evidence of operation effectiveness.|
| Inspection | Review records or documents supporting and evidencing the operation of a control. |
| Re-Performance | Re-perform the operation of a control to ascertain that it was performed correctly. |
| Knowledge Assessment | Combine inquiry, inspection and re-performance techniques to test the individuals’ knowledge of a subject or competency to perform a control. |
| Corroborative Inquiry | Corroborate the performance of a control through confirmation with other members of the organization. Corroboration is meant to confirm the validity and consistency of the application of the control as a test of operating effectiveness. |
| System Query | Test that automated controls within an IT application are operating as expected.|
**Appendix C: Testing Steps by Control Category**
`Authorization (Manual & System)`
*Definition*
Authorization includes:
* Approval of transactions executed in accordance with management’s general or specific policies and procedures.
* Access to assets and records in accordance with management’s general or specific policies and procedures.
*Points to consider when performing the listed test steps:*
* Select a sample of documents per the sampling guidelines.
* Review the sample for evidence of documented approval/authorization. Inspect documentation evidencing authorization (signatures or computer generated audit trail).
* Review to ensure approval/authorization is in compliance with the company Policy.
* Discuss the authorization process with those involved and understand if the process is appropriately controlled. Specifically, understand if the control has ever been circumvented and if these instances are appropriately controlled with appropriate parties notified.
* Discuss with Information Technology the mechanism for maintaining the appropriate schedule of authorizations within the system. Determine if terminated/resigned employees are removed from the list immediately on the effective dates.
* Determine if the existing authorization capabilities within the system are consistent with the Corporate Policy and if the process is appropriately controlled. If management review is performed consider using their test work to gain evidence related to effectiveness of the control.
* Inquire if the control has ever been circumvented and if these instances are appropriately controlled with appropriate parties notified. If the computer facilitates authorization, perform system query to determine whether the system access prohibits unauthorized processing.
`Exception/Edit Report Control`
*Definition*
Controls that fall into the exception/edit report category relate to when a report is generated to monitor something and followed-up on through to resolution. In most instances, the reports are focused on exceptions/edits as defined below, however in some instances it may just be a report. For example, if an aging report is generated by the system and followed up, the content does not necessarily represent edits or exceptions, but the control would fall into this category for test of design and test of effectiveness considerations.
* Exception - a violation of a set standard
* Edit - a change to a master file
In most instances the underlying data for an exception/edit report is to be tested.
*Points to consider when performing the listed test steps:*
* Select a sample of exception/edit reports per the sampling guideline.
* Inquire if operational or system changes have been made since the last review and if the exception/edit reports have been updated.
* Evaluate if the sample of reports have been generated with the frequency listed in the company policy. Inspect exception/edit reports considering:
- Date of preparation (frequency)
- Evidence of follow-up and corrective action
* Evaluate if the noted exception items on the selected reports are followed-up and resolved on a timely basis.
- Assess the competency and knowledge of individuals responsible for follow up. Consider re-performance and use judgment to gather sufficient evidence to conclude.
- Inspect evidence of follow up. Use judgment to gather sufficient evidence to conclude on whether follow up was appropriate.
- Document name, dates, and summary of interview and follow up action taken.
- Where this control is performed by a group/department also consider using the corroborative enquiry technique.
- If the report is computer generated and key configured controls are used to compile the report, use the configuration/account mapping control category for consideration to ensure the compilation of the report and underlying configuration are appropriate.
* Determine if the unresolved items are tracked and reported to the next level.
* Evaluate if the exceptions on the selected reports have been documented and approved.
`Interface/Conversion Control`
*Definition*
*Data interfaces* – Data interfaces transfer specifically defined portions of information (data) between two computer systems, using either manual or automated means or a hybrid of both, and should ensure accuracy, completeness and integrity of the data being transferred. The job of a data interface is to transfer the data securely, once and only once, completely, accurately, with integrity, and to highlight any exceptions. Interfaces can be two-way (back and forth between two systems) or one-way (from one system to another), and can link new systems to old/Legacy systems or old/Legacy systems to new systems.
*Data conversion* – Data conversion is the process of migrating data from a Legacy system (which may have old, duplicate, inaccurate, incomplete data, which reside in several places within the system) to a new system. To perform this process, the data needs to be cleansed, reviewed and synchronized prior to conversion (a critical step), then mapped (which may include parsing or other manipulation), reformatted, translated, consolidated and loaded into the new system (which may include a time lag or delay during which new data is created). Once the data has been converted and loaded into the new system, it must be maintained to ensure its completeness, existence, accuracy and integrity.
*Points to consider when performing the listed test steps:*
* Select a sample of source data as per the sampling guidelines and trace to corresponding converted data/system in order to ensure the data was converted/interfaced accurately and completely.
- Inspect documentation supporting initial design, function, implementation, including testing, and use judgement to gather sufficient evidence to conclude on whether it is appropriate.
- Corroborate understanding of changes (whether made or not) with an IT and business owner and confirm that maintenance is performed on regular basis.
- If changes were made in current year, inspect documentation of change ensuring procedures appropriate and authorized. Use judgment to gather sufficient evidence to conclude on whether it is appropriate.
- Perform procedures related to system access to change configuration as outlined in the system access control category.
* Inquire about steps taken to ensure that data has been accurately and completely transferred. Determine if the following exist:
- Items count or record count
- Batch total or hash total
- Integrity reports (e.g., out of balance report, unmatched sub ledger report)
- Reconciliation of input to output
Select samples of interface controls identified from the above and re-perform the steps to determine if the interface is complete.
Inspect exception reports generated highlighting interface problems. Follow through on the resolution of an exception that occurred this year. This exception review may include on-line review exception messages evidence during observation procedures.
* Inquire about the interface/conversion process. Determine if:
- Manual intervention can occur during the interface process
- Manual adjustments are identified and reviewed by a second person
* Determine if processing/job schedules exist and are monitored. Review the processing/job schedule to determine if the following are defined:
- Timeline when data entry can be performed
- Timeline when data entry cannot be performed (e.g., data is locked)
- Submission deadline for data feed
- Timeline for job submission
- Timeline for job run
- Timeline for job completion
`Key Performance Indicator (KPI)`
*Definition*
Key performance indicators (“KPIs”) are the financial and non-financial quantitative measurements that are:
* Collected by management, either continuously or periodically; and
* Used by management to evaluate the extent of progress toward meeting management’s defined objectives.
Points to consider when performing the listed test steps:
* Perform a trend analysis of the selected KPI & identify any unusual fluctuations.
* Determine if the listed/expected KPIs are calculated appropriately and timely.
* Determine if the listed/expected KPIs are reviewed and appropriate action is taken if the KPI’s fall outside the standard.
* Inspect evidence of follow up. Use judgement to gather sufficient evidence to conclude on whether follow up was appropriate.
* Assess the knowledge of individuals responsible for follow up. Consider re-performance and use judgement to gather sufficient evidence to conclude.
* Document name, dates, and summary of interview and follow up action taken.
* Inspect KPI documentation considering:
- Date of preparation (timeliness)
- Documented explanations for unusual fluctuations
- KPI agrees to the related books/records
* Evaluate appropriateness of established standards based on the company’s performance levels.
Additional considerations in gathering sample of KPIs:
Select only those KPIs that are both relevant to financial statement assertions and possess the following qualities:
* Strong and valid;
* Expected to produce reliable results; and
* At an appropriate level of precision to detect significant misstatement (as defined by the Assessor).
`Management Review`
*Definition*
Management review is the activity of a person different than the preparer, analyzing and performing oversight of activities performed. In many instances, it will be a manager reviewing the work of a subordinate. However, it is not limited to this. It may include co-workers reviewing each other’s work. Examples including internal audit activities, etc.
*Points to consider when performing the listed test steps:*
* Select a sample of documents per the sampling guideline.
* Review sample for documented evidence management review.
* Assess the competency and knowledge of individuals responsible for follow up. Consider re-performance and use judgment to gather sufficient evidence to conclude.
* Inspect evidence of follow up. Use judgment to gather sufficient evidence to conclude on whether follow up was appropriate.
* Document name, dates, and summary of interview and follow up action taken.
* Inspect supporting documentation evidencing review (e.g., signatures, board minutes, journal entries, etc.)
* Determine if management has adequately documented their review, identified unusual items/trends/variances and that the issues noted have been appropriately researched and resolved timely.
- If management review is performed in excess of another controls (e.g., a reconciliation the other control is reviewed by management) only one or the other controls may need to be tested (reconciliation or management review) depending on which is designed well and consider providing best evidence.
`Reconciliation`
*Definition*
Reconciliation is a control designed to verify that two items, such as computer systems, are consistent.
*Points to consider when performing the listed test steps:*
* Select a sample of reconciliation documents per the sampling guidelines.
* Review the sample for evidence of secondary review.
* Inspect reconciliation(s) considering:
- Agreement to the books/records reviewed
- Timely date of preparation
- Reconciliation balances
- Significant unidentified reconciling items that might represent a balancing amount (e.g., captions such as unlabeled “differences” or “other”)?
* Review to ensure the review process is in compliance with the company Policy.
- If there is management review consider whether the initial preparation and follow up or reviews will provide the best evidence control and test appropriately. (Also see management review control category)
* Verify balances to source systems (e.g., trace GL balance to GL).
* In the sample selected determine if the reconciling items have been identified appropriately researched and resolved timely.
* Determine if segregation of duties is maintained between those processing/approving the transaction and those performing the reconciliation.
`Segregation of Duties`
*Definition*
The separation of duties and responsibilities of authorizing transactions, recording transactions and maintaining custody to prevent individuals from being in a position to both perpetrate and conceal an error or irregularity.
*Points to consider when performing the listed test steps:*
* Understand by inquiry and observation whether there is adequate segregation of duties among those that authorize transactions, record transactions and maintain custody of assets.
- Inspect the accounting policies and procedures manual noting that segregation of duties policies and procedures (specific to the area reviewed) are documented.
- Use the corroborative enquiry technique to corroborate segregation.
* Perform review of individuals and the tasks they perform, and review their user profile to determine if their system access allows the segregation of duties (i.e., the system access is limited to the tasks they perform and does not compromise the segregation of duties).
`System Access`
*Definition*
The ability that individual users or groups of users have within a computer information system processing environment, as determined and defined by access rights configured in the system. The access rights in the system agree to the access in practice.
*Points to consider when performing the listed test steps:*
* Inquire about the maintenance process of granting and limiting access to system/transaction to appropriate personnel and determine if:
- Terminated/resigned individuals are removed immediately from the system on the effective date; and
- Segregation of duties is maintained in granting access to individuals.
* Obtain listing of individuals with access to the system/function noted in the control description from the IT department.
- Corroborate knowledge of individuals with respect to their understanding of their own access capabilities. Compare responses to managements understanding and/or established guidelines.
- Perform system queries with respect to the following to corroborate understanding of access restrictions gained through discussions regarding:
- Level of access;
- Super user access; and
- Sensitive functions.
* Select a sample of users from the list in accordance with the sampling guidance and obtain authorization/approval documents sent to IT for system access to review for evidence of appropriate approval/authorization.
* Review the listing and assess appropriateness of the user profile for the users identified. If inappropriate user profiles are identified, obtain explanation and request listing of transaction performed by the individuals to determine if unauthorized/inappropriate transactions exist.
* Determine if the user profiles and user access are subject to periodic review and if management has adequately documented their review and the issues of note have been appropriately researched and resolved.
* Determine if security violation reports are generated & security breaches are followed up and investigated. Inspect exception reports generated highlighting exceptions to access restrictions. Follow through on the resolution of an exception that occurred this year and use judgment to obtain sufficient evidence to conclude on follow up (this may include on-line review of user profiles).
`System Configuration/Account Mapping Control`
*Definition*
System configuration and account mapping includes “switches” that can be set by turning them on or off to secure data against inappropriate processing, based on the organization’s business rules. If the switch is turned on, the checking can be customized for the particular organization to be very robust or very permissive. The more specific definition of each is as follows:
* Configurable controls - specific “switches” that can be set by turning them on or off to secure data against inappropriate processing.
* Account mapping - specific “switches” that can be set related to how a transaction is posted to the general ledger and then to the financial statements.
*Points to consider when performing the listed test steps:*
* Inquire if financial, operational or system changes have been made since the last review and if configuration/account mapping has been updated.
- Inspect documentation supporting initial design, function and implementation including testing and use judgment to gather sufficient evidence to conclude on whether it is appropriate. (This is to be completed in the first year of relying on the control and whenever there is a change in IT environment or system)
- Corroborate understanding of changes (whether made or not) with an IT and business owner and confirm that maintenance is performed on regular basis.
- If changes were made in current year, inspect documentation of change ensuring procedures are appropriate and authorized. Use judgment to gather sufficient evidence to conclude on whether it is appropriate. Perform procedures related to system access to change configuration as outlined in the system access control category.
* Select a sample of business rules and account mapping for review. Determine if the business rules and account mapping are valid with reference to current policy and procedures.
* For a sample of business rules and account mapping established, determine if system edit checks are set up to detect and prevent abnormalities. Perform the following:
- Run systemic edit checks (e.g., posting limits, tolerance limits, validations and security settings) with a set of fictitious data to determine if these checks are in place and adequately functioning.
- Perform data mining against the database to determine if out of range data exists. Explain exceptions noted.
* Obtain a listing of account mappings to determine if all accounts set up in the database have been mapped to a correct GL account.
* Inquire with the Information Systems Department about the user’s ability to change configuration and account mapping. Determine if change management procedures exist to track requests, changes made and perform testing prior to changes being implemented and released. Inquire if changes can be made and go undetected.
`Additional Consideration in Testing Configurable Controls or Account Mapping:`
Account mapping may be changeable in a “live” production environment by users. Mis-mapped accounts may not appear on the financial statements, or they may appear in an inappropriate manner such as in a suspense account or in an “opposite” category such as revenue to liability. An end user can circumvent configurable controls if the control is not appropriately set up to meet the company’s need and user access appropriate. For example, using the warning message “can continue” may not be as appropriate to meet the company’s needs as “cannot continue - transaction is “held/blocked.”
Configurable controls can override security control features. For example, not assigning “authorization groups” to certain accounts, tables or programs can result in ineffective security. On the other hand, a configurable control can be set up but may not be effective unless the system access supports the control as configured (for example: a user with super user access can just change the configured control setting).
# Disclosure Committee Charter
[Model Disclosure Committee Charter](https://www.sec.gov/Archives/edgar/data/1432754/000129460609000035/exh993.htm) by [SEC](https://www.sec.gov/).
GitLab has adequate internal controls and disclosure procedures in place to ensure that its periodic reports, quarterly earnings releases, proxy statements and registration statements are accurate and complete, and upon which the senior officers of the company have relied in making decisions on disclosure issues in connection with such public disclosures.
The company’s current internal processes have been memorialized in various locations in the handbook, but shall be summarized separately as a table on this page entitled, “GitLab’s Disclosure Controls Policy and Procedures,” to be prepared as soon as possible.
The company’s disclosure controls and procedures serve the purpose to help appropriate personnel make decisions on disclosure issues.
The United States Securities and Exchange Commission (the SEC) adopted new rules 13a-14 and 15d-14 under the Securities Exchange Act of 1934, effective as of August 29, 2002, which implement [Section 302](https://www.sarbanes-oxley-101.com/SOX-302.htm) of the Sarbanes-Oxley Act of 2002 (the Exchange Act Rules).
The [Exchange Act](https://www.sec.gov/answers/about-lawsshtml.html#secexact1934) Rules require the company’s chief executive and chief financial officers (each a certifying officer and collectively, the certifying officers) to certify in each of the company’s periodic reports filed with the [SEC](https://www.sec.gov/), among other things, that he is responsible for establishing and maintaining disclosure controls and procedures, and that, as of a date within 90 days prior to the filing date of the applicable report, he has evaluated the effectiveness of the company’s disclosure controls and procedures.
It is necessary and appropriate to establish the GitLab Disclosure committee (the committee), which is intended to implement disclosure controls and procedures necessary to meet the requirements set forth in the Exchange Act Rules and other provisions of the [Sarbanes-Oxley Act of 2002](https://www.sec.gov/answers/about-lawsshtml.html#sox2002).
The company’s chief executive officer and chief financial officer have established the committee pursuant to and vested it with the powers and responsibilities set forth in this charter.
**Purpose**
The purpose of the committee is to assure that information required to be disclosed by the company in the reports that it files or submits under the Exchange Act is properly recorded, processed, summarized and reported to senior management as appropriate to allow timely decisions regarding required disclosure. The committee will also evaluate the adequacy of the company’s disclosure controls and procedures with respect to its periodic reports and quarterly earnings releases.
**Members**
The committee shall consist of the following individuals as each holds the corresponding position within the company:
| Title |
| ------ |
| Chief Financial Officer |
| Principal Accounting Officer|
| Senior Technical Accounting Manager |
| Accounting and External Reporting Manager|
| Senior Internal Audit Manager|
| Vice President of Investor Relations|
| Vice President of FP&A|
| Chief Legal Officer|
| Director of Risk and Compliance|
In addition, internal audit shall serve as an ex-officio participant of the committee. Ex-officio participants will not have the right to vote at committee meetings. The committee members may call on other company team members to participate in committee meetings as needed, but such team members will not have the right to vote at committee meetings. The chair and co-chair of the committee shall have the authority to appoint and remove individuals from the committee as they deem appropriate, provided they notify the chief executive and chief financial officers. Any individuals appointed as successors to the above positions shall succeed that member of the committee, unless the chair and co-chair direct otherwise.
**Meeting**
The primary channel of work will be GitLab issues or GitLab slack channel `#disclosure-committee` where all committee members have access to the information, discussion, conclusions and action plans.
The committee shall meet at the discretion of the chair and co-chair, provided that the committee shall meet not less than once per quarter. This will coincide with public filings of the Company. The chair or co-chair may call meetings by providing a minimum of 24 hours advance notice of the time of the meeting to all members of the committee.
The chair or co-chair may designate an assistant secretary to assist the secretary in keeping minutes of the committee meetings as appropriate to record the meetings and decisions taken with respect to disclosure issues. The minutes (or a briefing of the issues discussed and decisions taken with respect to disclosure issues) of each meeting will be distributed to the chief executive and chief financial officers.
**Functions**
In order to achieve its purpose, the committee will perform two functions. First, it will identify and consider disclosure issues in connection with the preparation of periodic reports and quarterly earnings releases and participate in the review of such disclosures. Second, it will undertake a quarterly evaluation of the company’s disclosure controls and procedures.
1. *Identification and consideration of disclosure issues*
The members of the committee will continue to follow the internal processes set forth in the disclosure controls and procedures documented by the company pertaining to the preparation of periodic reports required by the federal securities laws and the preparation of quarterly earnings releases. As part of this process, the committee shall:
- Review the company’s periodic reports, with a particular focus on “Management’s Discussion and Analysis of Financial Conditions and Results of Operations” and the “Financial Statements and Footnotes to the Financial Statements”. - Review and discuss with the controller’s group whether the company’s periodic reports and earning releases provide a fair presentation of the company’s financial condition, results of operation and cash flows.
- Assess the materiality of specific events, developments or risks to the company
- Review financial reporting issues that are significant to the company and other material reporting matters where the person primarily responsible for such matters made significant judgments (either independently or in consultation with others).
2. *Evaluation of disclosure controls and procedures*
Each quarter, the committee shall review and evaluate the effectiveness of the company’s procedures for recording, processing, summarizing and reporting information required to be disclosed by the company in its Exchange Act filings. As part of this review and evaluation, in connection with the preparation of the company’s annual report, the committee will assess the effectiveness of the company’s internal control structure and procedures for financial reporting.
The committee shall submit a written report documenting its quarterly conclusions about the effectiveness of the disclosure controls and procedures and annual assessment of the internal control structure and procedures for financial reporting to the company’s chief executive and chief financial officers. Such reports shall be submitted as soon as practicable after the respective reporting period.
**Timetable for the preparation of annual and quarterly reports**
| Days Prior Filing Date | Task |Responsible Parties |
| :------| :------ |:------ |
| More than 30 days | Appoint principal draft personnel|Certifying officers |
| 30 days | Begin drafting report and collect information | Principal draft person |
| 20 days| Distribute initial draft to certifying officers, disclosure committee and business decision makers |Principal draft personnel |
| 20 days| Distribute supporting materials to certifying officers and disclosure committee | Principal draft personnel |
| 18 – 20 days | Review draft and commence meetings |Certifying officers, disclosure committee and personnel responsible for business of subsidiaries, divisions or departments, and key geographic regions (the business decision makers)|
| 18 days | Provide initial comments to principal draft personnel | Certifying officers, disclosure committee and business decision makers |
| 15 – 18 days| Certifying officers discuss with senior accounting staff and business decision makers |Certifying officers and business decision makers|
| 15 days | Provide comments to principal draft personnel| Certifying officers, disclosure committee and business decision makers|
| 12 days | Provide revised draft to certifying officers, disclosure committee and business decision makers, and initial draft to outside auditors and outside counsel|Principal draft personnel|
| 10 – 12 days| Review draft|All parties |
| 9 – 10 days | Certifying officers meet with outside auditors |Certifying officers and outside auditors |
| 9 days | Provide comments to principal draft personnel |All parties |
| 7 days | Distribute revised draft to all parties and audit committee|Principal draft personnel |
| 5 days | Certifying officers and disclosure committee meet with audit committee |Certifying officers, disclosure committee and audit committee |
| 5 days | Audit committee meeting|Audit committee, CFO, outside auditors and outside counsel|
| 4 days | Distribute to all parties substantially final draft|Principal draft personnel |
| 2 – 4 days| Provide final comments|All parties |
| 1 – 2 days | Finalize and [EDGARarize](https://www.sec.gov/edgar.shtml) report |Principal draft personnel|
| Filing Date| File report |Principal draft personnel |
**Appointment of principal draft person**
The principal accounting officer shall initially serve as the principal draft person of the company’s annual and quarterly reports. The principal draft person shall be responsible for preparing and filing each report; coordinating meetings between the certifying officers and committee, the audit committee, and the company’s outside auditors; working with counsel; coordinating the receipt of comments and implementation of changes suggested by all persons involved in the review of each report; and ensuring that the timetable for preparation of each report is followed.
**Amendments**
The committee shall review and reassess the adequacy of the committee’s charter at least annually. If the committee deems it necessary or appropriate to revise the charter, it may submit proposed revisions first to the company’s chief financial officer and then to the chief executive officer for review and approval. This charter may be amended upon written direction or approval from the chief executive officer and chief financial officer of the company, provided they notify the company’s audit committee of such amendment.
# GitLab’s Disclosure Controls Policy and Procedures
**Purpose**
This policy documents the overall controls and procedures designed to ensure the quality and accuracy of disclosures made in GitLab’s quarterly and annual public filings with the US Securities and Exchange Commission.
**Policy**
Overall controls are established to ensure a schedule of events and responsibility list are developed for each reporting period, disclosable items are identified with sufficient lead-time to allow for:
* Proper assignment of responsibility
* Efficient and effective data gathering and processing
* Streamlined company-wide comprehension and consensus
This is intended to:
1. Enhance the completeness and accuracy of the information reported in quarterly SEC filings.
2. Facilitate the timely certification of quarterly SEC filings by business unit, disclosure committee, and audit committee personnel, and
3. Ensure the timely, composed satisfaction of increasingly stringent quarterly SEC filing deadlines
**Responsible Parties**
| Function | Title |
| ------ | ------ |
| Financial Reporting |Principal Accounting Officer, Senior Technical Accounting Manager and Accounting and External Reporting Manager |
| Accounting | Principal Accounting Officer, Controller and Senior Accounting and Operations Manager |
| Finance | Principal Accounting Officer, Controller and Vice President of Finance |
| Legal | Chief Legal Officer and Vice President of Legal |
| Business Operations, forecasting and planning | Vice President of Finance, Vice President of Financial Planning and Analysis |
| Compliance | Director of Risk and Compliance |
| Tax | Director of Tax |
**Procedures**
Quarterly Process: The “working group” is defined as a member committee comprised of representatives from the following business units: Financial reporting, Accounting, Finance, Legal, Business Operations, forecasting and planning, Compliance and Tax. The working group is primarily responsible for tasking the appropriate business unit individuals with ensuring the completeness, accuracy, and timeliness of information related to significant disclosable items. The working group reports directly to the disclosure committee.
* The working group is primarily responsible for the early identification of significant disclosable items driven by either:
- External reporting requirements or
- Company events, transactions, business arrangements, and/or outlooks.
* On or before one month before quarter-end, the members of the working group initiate discussions with their respective business unit contacts regarding any company events, transactions, business arrangements, and/or outlooks that have transpired since the previous quarter.
Each working group member can utilize a [Financial Disclosure Communication Questionnaire](https://docs.google.com/document/d/1fDTuwxAOccJh_FZmMYW0lex9nBcLgX_YPZDQHowor0Q/edit?usp=sharing), as appropriate, to formally facilitate and document the preparatory discussions with their business unit contacts. By two weeks before quarter-end, working group agenda items are prepared for the initial pre-close planning meeting.
* Approximately two weeks prior to the quarter-end meeting, the members of the working group formally meet to discuss disclosable items for the upcoming quarter. Attendance is taken at the meeting and an agenda is provided for the meeting.
* In lieu of formal meeting minutes, a [Footnote/Disclosure Planning Record](https://docs.google.com/document/d/1wyGTNYL3KIOOouDCw7ojIB17Fx0kOB5qBHwAZOlfnK8/edit) is produced by the working group during the meeting. The Footnote/Disclosure Planning Record is a summary of all significant disclosable items that have arisen during the current quarter. The working group assigns a three-tiered layer of responsibility to each disclosable item as follows:
- Source – Business unit personnel responsible for providing complete, accurate, and timely information relevant to the significant disclosable item to financial reporting.
- Preparer – Financial reporting personnel responsible for incorporating information relevant to the significant disclosable item into the 10-Q in a timely manner.
- Monitor – Working group personnel responsible for overseeing the progress of both the source and the preparer who are assigned to the significant new disclosable item.
If the initial pre-close planning meeting does not result in the complete identification of all significant new disclosable items, or does not result in the complete source, preparer, and monitor responsibility assignments, then a subsequent pre-close planning meeting is held as soon as practically possible (but by no later than reporting date for formal disclosure committee).
* Requests for information relevant to significant disclosable items are made by the assigned preparers through the company database as soon as practically possible, but by no later than the final report date to disclosure committee. Responses to such information requests are made by the assigned sources through the company database as soon as practically possible, but by no later than one week before the planned release of the working group report. For all disclosable items, the assigned Sources also complete a [Disclosure Cover Sheet](https://docs.google.com/document/d/1ZVsQr8XT3WB5Cy7-p2OoYHyJDzPuC0mj4QyuRxnmH5Y/edit).
*Key Control # DC.01*
1. Accounting and External Reporting Manager will be responsible for:
1. Updating the Footnote/Disclosure Matrix on a quarterly basis for all disclosable items,
2. Ensuring the timely receipt of a properly prepared Disclosure Cover Sheet for each disclosable item, and
3. Warehousing this documentation within the Workiva tool.
2. An initial draft of the 10-Q, along with the Footnote/Disclosure Planning Record modified to include draft references, is made available for business unit review by the specified deadline. Any comments from all business unit personnel are due to their corresponding working group representatives by comment period ends. The working group representatives filter the comments from their respective business units and present a unified set of suggestions to the financial reporting representative, who then routes the comments to the appropriate financial reporting personnel for final disposition. A revised draft of the 10-Q (and the accompanying Footnote/Disclosure Planning Record) is completed by the agreed upon date.
3. Comments from the disclosure committee are received and incorporated into the 10-Q (and the accompanying Footnote/Disclosure Planning Record) and communicated to the audit committee.
4. The 10-Q is formally filed with the SEC within due date.
5. The goal is to file the 10-Q day after or shortly after the earnings release.
