The Science of Compliance

'William Brewer takes a look at what is involved with IT 'Compliance', and discusses what SOX compliance means for the DBA and IT Application developer.'

There is nothing new about ‘compliance’, whether this refers to compliance with industry regulations, with federal/European/government regulations or with company policy. The IT part of any public company must not only comply with legal requirements, but also be able to prove its compliance. It has a responsibility to the investors, customers, management, employees and the general public to do so.

Compliance is a broad subject, because there are so many regulations out there, and they occasionally contradict each other. Nevertheless, the management of any IT department has to do their best to ensure that they are complying with them. It must, for example:

  • Be certain that financial business transactions are logged, monitored, and correctly reported.
  • Be confident that the areas of risk to the integrity of data are known about and that all reasonable controls are in place to minimise that risk.
  • Be confident that Change Management is efficient, effective, and economical.
  • Know that all systems using Payment Cards are in line with industry regulations.
  • Be sure that all information held in IT systems is secure, correct, and protected, and that its risk-management strategies are up to standard.
  • Be confident that IT Governance and Strategy, including management’s philosophy and operating style is complete, effective and sustainable.
  • Ensure and maintain the uncompromising integrity, ethical values and competence of all levels of the enterprise
  • Check that controls such as approval processes, authorizations, verifications, reconciliation procedures, reviews of operating performance, security of assets and segregation of duties, are documented and being used

Auditing and Liability


Corporate IT departments have always been required to ensure that all financial systems are ‘auditable’, and that they comply with statutory requirements. What has changed more recently is that there are far more statutory requirements, and that senior management, including CEOs and CFOs, can now be held personally liable for the accuracy of company financial reports, and the internal control processes used in the generation of these reports. They can also face severe penalties if financial reports are untimely or inaccurate. Unsurprisingly, this has focussed attention on one of the less exciting functions of an IT department.

External auditors must now state whether effective internal control over financial reporting was maintained, as well as stating whether the financial statements were accurate. In order for the external auditors to be able to certify that the published financial results accurately represent the financial state of the organisation, they must feel complete confidence in the integrity of the data produced by every financial system that feeds into the bottom-line trading figures. Only a combination of procedures and internal controls can provide this assurance.

Both the auditors and senior executives need to feel confident that they can state that authorized users are recording and cross-checking all financial transactions, that data has not been compromised in any way, and that all changes to the financial data of the company are monitored.

Clean SOX

In most companies that are involved in finance and financial services, where the culture is based on financial business processes, this is already being done. IT management have a long-standing responsibility to the company they work for, to be able to identify all financial systems, to log, review, cross-check and test all changes to a high standard, and to be able to provide the historical details of all financial transactions sufficient for the requirements of a full audit. The difference now is that legislation and standards such as Sarbanes-Oxley, J-SOX(Japan), Bill 198 (Canada), FSA, LSF (France), HIPAA, HSPD-12, King report (South Africa), BASEL II, SEC, FASB (Financial Accounting Standards Board), CLERP9 (Australia), Gramm-Leach-Bliley, SEC and PCAOB have made these obligations more explicit.

The event that turned everyone’s attention onto these IT processes was the coming of SOX. In 2002, The USA Congress passed the Public Accounting Reform and Investor Act, which is now more generally known as the Sarbanes-Oxley Act (SOX). This act was designed to combat the rise of corporate fraud that was threatening to cause a public loss of confidence in commerce. It was wide-ranging in its scope, but Section 404 of the act specifically requires all IT departments of public companies to audit the systems that deliver financial reports, and makes the company management and the external auditor responsible to report on the adequacy of this “internal control” over financial reporting (ICFR).

” Controls are there
to provide independent crosschecks “

“Internal control”, in this context, refers to a system of checks and balances that are designed to combat fraud, and to ensure that changes to financial applications do not introduce inaccuracies in financial transactions or reports. Controls are there to provide independent crosschecks to prevent fraud, misreporting and tampering. Control activities occur throughout the organization, at all levels and in all functions. Any auditor in the US may now require “Attestation” reports from IT departments to spell out their compliance with the Sarbanes Oxley Act. The auditors will also check that every IT system identified as being financial in nature can produce reports that can reconstruct what actually happened to specific financial transactions, including time sequences for processing and all related activities.

Meeting SOX Standards

Sarbanes-Oxley, Section 404, requires that the process used to generate financial statements be accurate and meet an accepted industry standard. But what is the accepted standard? The nearest we have in the USA is the IFC’s COBIT, (Control Objectives for Information and related Technology). COBIT is the umbrella framework for IT governance because it is harmonised with other standards and continuously kept up to date. It tells you ‘what’; the ITIL (IT Infrastructure Library) will tell you ‘How’.

ITIL emphasizes the need for security policy and measures to be implemented at the perimeter (such as data input) and application levels, as well as data audit trails and logging. ITIL specifies that all financial systems, including those systems feeding into them, have to be identified and should be included in the reviews and assessments of internal controls. The flow of transactions, including IT aspects, has to be sufficiently understood to identify points at which a misstatement or fraud could arise. A trusted, independent audit trail is essential to any internal control system, to identify weaknesses and successes in systems, processes or procedures. It is, of course, an absolute necessity during reviews for compliance – whether complying with industry or federal regulations or with company policy.

An audit trail has to be securable, independent and should capture all changes to data automatically, regardless of the source. This requires a database-level mechanism to log and report the ‘who’ made the changes, ‘what’ changes were made, and ‘when’ the changes happened. In addition to recording the ‘who, ‘what’, and ‘when’ of all data changes, it must also record the identity of the application and workstation used to make the change (the ‘how’ and ‘where’).

SOX and the DBA

All of the above should represent existing good practice, and familiar to any IT professional who has ever worked on financial systems. Effective auditing involves not only detailed and effective logging of all transactions, but also a detailed record of privileged user behaviour, direct access to sensitive data stores, user privilege escalation, failed login and failed database operations.

” It is not enough to do it.
He must prove it is being done “

As part of the new audit standards, a DBA must now prove that he is continuously monitoring and recording all database changes, including any changes to data structures, when they happened, and who made them. It is not enough to do it. He must prove it is being done. He must also monitor, log and audit the activity (from privilege escalation events and failed logins to schema changes and direct SQL access events) of privileged users who have the highest level of access to systems. He must enforce the segregation of duties based on user roles, correlate all database and file server changes to the company’s change control systems to ensure only approved changes are taking place, and provide regular summary and detailed reports on all data activity. All these activities should be documented as control procedures, which can be checked by the auditors.

Most financial systems have built-in audit trails at the application level, but these aren’t sufficient to check that data was not changed by another process outside the financial application (such as a batch job, query or other application). To assure data integrity, it must be possible to generate a complete audit trail of all changes that have been made to the data – recording who, what, when and where, regardless of where or how the change was made. An auditing system that operates at the database level, rather than the application level, is really the only means to ensure auditing of all data changes made through any possible interface.


The IT controls and practices that have existed for years in well-run enterprises in the banking sector have become more generally required by legislation. This has been done by international consensus in order to combat the worldwide rise in fraud, and increase the chances of successful investigations and prosecutions.

” controls must be documented in
sufficient detail to satisfy the auditors “

Any IT system that has any influence over the period-end financial reporting process, and the controls on these systems, must now be identified explicitly and documented. The areas of the business that are most at risk from fraud have to be assessed and controls be put in place that are designed to prevent or detect fraud. These controls must be documented in sufficient detail to satisfy the auditors. Areas of particular interest should be the monitoring of any mechanism whereby management or staff can override these controls. It is important to ensure that all financial transactions are recorded and logged in such a way that there will be a history of any attempt at intrusion or manipulation, and all evidence of tampering will show up, and can be crosschecked, in a subsequent audit trail.

The objective of all this work is to ensure that businesses are conducted with complete integrity, and can prove that all sensible precautions against fraud and misrepresentation are in place. In the event of any attempt to tamper with financial data, it must be possible to determine the details of what happened so clearly and unambiguously that it could then be used as evidence.