Audits; even more emotion invoking than one of our latest posts around logs. Shrouded in secrecy, an IT audit can be a resource-intensive exercise. IT audits touch people, process, and technology [similar to the DevOps mantra]. There are certainly many flavors of IT audits ranging from capability assessments to compliance/regulatory based audits.
IT audits are intended to make sure our controls are effective. Depending on when we come into a project, the ever in the horizon IT audit would be going through technology and control decisions made before our time on the project. As we learn about the systems and platforms we have to develop features on a new project, explaining how the systems and platforms are put together can be challenging. IT audits are not all bad and important to fulfilling compliance in regulatory mandates. Even if your organization is not under regulation, IT audits can still be in your future.
Chances you will get an IT audit?
You don’t have to be a healthcare provider providing services to the Federal Government to get audited. Pretty much any organization has some sort of audit requirement to appease. Even if you are a small startup, eventually you will come across a client who will want a copy of an audit or as your startup grows just a good practice to have some sort of baseline.
Though regulation can be a driving force of an audit for your organization. If your organization has the presence of one of these acronyms, most likely a regulatory audit is in your future. These types of audits can range in frequency of yearly to multiple times a year.
PCI: Payment Card Industry Data Security Standard [PCI DSS]: If you take credit card payments depending on how many you process in a month, PCI DSS dictates security standards that are needed.
HIPAA: Health Insurance Portability and Accountability Act: More focus on the accountability part, patient privacy and protection especially as we move towards electronic health records [EHR].
FISMA: Federal Information Security Management Act: If you are touching anything federal, FISMA will have an impact on you.
Another common type of IT audit is called a SOC 2. Stemming from the American Institute of CPAs [AICPA], a SOC 2 measures security, availability, and integrity of data stored in the cloud. For most companies that have a SaaS model, going through a SOC 2 audit is par for the course at some point in their maturity.
IT audits can also be used to gauge the capability and maturity of your organization’s IT landscape. Most likely the capability audits will be carried out by a consulting firm or analyst firm specializing in your particular industry. Unlike a regulatory/compliance audit, a capability-based IT audit is more ad-hoc and triggered by a business decision.
IT audits as time-consuming as they can be are comprised of a few basic components of information gathering and finding sharing.
What is it like to be in an Audit?
Usually in an audit depending on the auditor need to answer questions with proof of a compensating control. Like showing your work in math. There needs to be a set scope (though can feel can be very wide) in terms of the audit.
For example, an audit requirement might be for passwords to be secure in customer-facing systems. The compensating control is a password to be at least six characters long. An auditor might request a copy of the password standard and proof of the policy and potentially would want to run the policy. You can see how time-consuming this can be.
Having an on-going relationship with the auditors also helps because there is a due-diligence period as the auditors to get ramped on understanding the business and why which controls are in place.
The remediation period can be as an audit is going on and some point after if there are negative findings giving you some time to make the recommended changes. Regulatory wise if your organization is really off the mark can be a mad scramble.
By leveraging a Continuous Delivery solution, you can have a program system of record allowing for shorter due-diligence periods and potentially more time to prove/remediate with the auditor and have less of a mad scramble.
Continuous Delivery - The Programmatic System of Record
I was working at bank under Dodd-Frank regulation and we had an odd requirement. We were required to go back five years on automated/programmatic decisions around credit approvals or declinations we made. Basically a replay of the data points and business rules we used.
The database for the datapoints was fine, but the application/business rules were the trouble spot. Boiled down to we had to re-deploy the application based on a date if a request came in for additional details. Now there is a good bit more than the JAVA distributions [aka WAR].
Since your Continuous Delivery solution should be the nexus of your release/deployment, the confidence-building steps and the composition of the application and artifacts are easy to extrapolate. Going back in time might be one use case for a Continuous Delivery solution; make sure the platform you choose allows for programmatic access to create an audit trail.
