What Are SOX Compliance Requirements?

Published March 26, 2020 by 4 min read

The Sarbanes-Oxley (SOX) Act was signed into law on July 30, 2002. The law drafted by congressmen Paul Sarbanes and Michael Oxley aimed to improve corporate financial governance and accountability while protecting shareholders from accounting errors and fraudulent activity. 

The real fuel for the SOX law came from the inappropriate financial conduct of three large companies Enron, Tyco, and WorldCom. SOX compliance impacts every public company in the United States and is the basis for financial data security.

One of the largest effects that the Sarbanes-Oxley Act of 2002 had on public companies is how to store corporate electronic records. The law doesn’t necessarily dictate how the records should be stored, but it does specify what kind of records should be stored and for how long. 

An organization needs to keep electronic records and messages for a minimum of five years. The records held are used for financial reporting as well as financial statements compliance requirements. While many companies leverage accounting firms to validate SOX compliance, Chief Financial Officers (CFO’s) work hand in hand with corporate information technology leaders to make sure that SOX is implemented enterprise-wide.

All public companies must comply with SOX and have rolled key components of the law into company business and information technology internal controls. There are several SOX compliance requirements that organizations leverage for corporate governance. The two primary sections from SOX are Section 302 and Section 404.

Section 302: Corporate Responsibility for Financial Reports – Safeguards your organization against faulty financial reporting. Special care is given to protect against inaccurate data, data that has been tampered with, or data that is faulty in general.  The essence of Section 302 states that the CEO and CFO are directly responsible for the accuracy, documentation and submission of all financial reports as well as the internal control structure to the SEC.

Section 404: Management Assessment of Internal Controls – All annual financial reports must include an Internal Control Report stating that management is responsible for an “adequate” internal control structure, and an assessment by management of the effectiveness of the control structure.  Data needs to be verifiable by a third-party auditor. The verified information is then shared with shareholders and public entities. The main point is to enforce security breach reporting as well as guarantee that auditors have access to verified information.

There are ten main compliance requirements that organizations should consider when seeking SOX compliance:

  1. Implement safeguards to protect against data tampering (Section 302.2)
  2. Establish safeguards to prove timelines (Section 302.3)
  3. Implement verifiable controls to track access to data (Section 302.4b)
  4. Prove that safeguards are operational (Section 302.4c)
  5. Report on a periodic basis the effectiveness of safeguards (Section 302.4d)
  6. Detect security breaches (Section 302.5a and Section 302.5b)
  7. Disclose safeguards to SOX auditors (Section 404.a.1.1)
  8. Disclose security breaches to SOX auditors (Section 404.a.2)
  9. Disclose failure of any security safeguards to SOX auditors (Section 404.b)
  10. Implement internal control framework (various mentions)

It is important to remember that the signing officer must validate and attest to the reported information.

Implement safeguards to protect against data tampering (Section 302.2)

The best way to safeguard against data tampering is to implement Identity and Access Management (IAM), Enterprise Resource Planning (ERP), and Governance Risk and Compliance (GRC) systems. The systems need to track who has access to what, what they are doing with the access, and whether that access is required. User access logs need to be tracked to identify any sensitive data access attempts or tampering anywhere that data is stored.

Implement safeguards to prove timelines (Section 302.3)

As with Section 302.2 IAM, ERP, and GRC systems are required. That being said, the real focus is on being able to prove timestamps as they occur in real-time. The information needs to be relayed for storage offsite when it is received. The reason for the transmission is to prevent alteration to the data record. Logs need to be stored offsite as well and an encrypted MD5 checksum must be used to prove data integrity. 

Implement verifiable controls to track access to data (Section 302.4b)

The implemented IAM, ERP, and GRC systems must scale to meet the demands of various data sources. The systems will collect data access controls from all data sources within the organization including but not limited to FTP, databases, and unstructured data. 

Prove that safeguards are operational (Section 302.4c)

Implemented systems need a way to prove they are operational. Several examples of compliance include daily digest emails from the systems, feeding health status to a Security Information and Event Management (SIEM), and reports published to an intranet.

Report on a periodic basis the effectiveness of safeguards (Section 302.4d)

The systems in the organization need layered reporting on overall environmental health. Robust systems contain self-check capabilities that help identify potential issues to security or availability. Alerts, reports, and messages need to be integrated with a ticketing system that has archive capabilities for auditable records.

Detect security breaches (Section 302.5a and Section 302.5b)

Threat Intelligence systems, as well as User and Entity Behavior Analytics (UEBA), need to be integrated with IAM, ERP, and GRC to aid in security breach detection. Notification and the ability to track and archive events are critical to SOX compliance. Ultimately an auditor is going to want to see what happened to cause the security breach and what was done to remediate and contain the damage.

Disclose safeguards to SOX auditors (Section 404.a.1.1)

Role-based access to systems is critical in SOX compliance. SOX auditors need access to systems, but only the right amount of access. Keys to the kingdom should not be given and instead, a specific auditor role needs to be created and leveraged for read-only report access.

Disclose security breaches to SOX auditors (Section 404.a.2)

The SOX auditor is going to want to see logs indicating any security breaches and how the breach was resolved. All events need to be archived and reported on at a later date. SIEM systems are a great way to track and present information to an auditor.

Disclose failure of any security safeguards to SOX auditors (Section 404.b)

Testing the resiliency of IAM, ERP, and GRC systems should happen on an ongoing basis. Auditors want to make sure that the identified safeguards in an organization are actually working. There is a wide variety of ways to test systems such as penetration testing and vulnerability scanning. Any testing needs to be recorded for future analysis.

Implement internal control framework (various mentions)

Internal control frameworks like COBIT or COSO are important to SOX compliance for three key reasons:

  1. Internal control framework adapts to the changing business environment
  2. Control frameworks mitigate risk
  3. Information governance and decision making are easier with structured controls.

Ultimately, SOX compliance is helping organizations verify that there are adequate controls protecting financial data. SOX compliance is required for public entities and private entities are encouraged to follow the same practices. 

SOX is in existence to prevent another scandal as we saw with WorldCom, Enron, and Tyco. Auditors exist to review and verify controls, while policies and procedures are in place to protect shareholders. It is in an organization’s best interest to make a SOX auditor’s job easier by providing seamless read-only access to systems, reports, and data.

Learn how we can fit into your business.

Schedule a demo to learn how we can help guide your organization to confidence in infosec risk and compliance.

Help us get to know you.

Get a demo