What Is an Audit?

An audit is a systematic examination by an independent expert on adherence to a well-defined standard. To be an audit, these three elements must be in place: the standard to measure against, neutrality of the examiner, and a systematic approach; otherwise, it’s an assessment, which implies informality. The standard’s governing body certifies the audit.

Regulated Industries That Require Audits

Any company working in the financial sector is probably already familiar with the obligation of audits. This includes banks, insurance companies, accountants, securities firms, and even pawn and payday loan shops. If an organization handles financial information, they fall under the Gramm-Leach-Bliley Act (GLBA) and its Safeguards Rule for protecting the privacy of their customers. GLBA itself is vague about specific technical measures that need to be put in place, but instead focuses on a risk-based approach with controls chosen by the organization to reduce that risk. This is the risk-based approach that this book focuses on, because it is very flexible and efficient.

There are additional security guidelines for GLBA described by the Federal Financial Institution Examination Council (FFIEC) , an interagency standards group of financial organizations. Even though the FFIEC is a non-regulatory entity, its guidelines are used as measures by auditors in the financial services sector. The FFIEC guidelines describe specific technological and procedural controls that should be in place. This is more akin to how other compliance frameworks and audits are structured. This list of controls is a guideline to verify risk treatment plans to make sure that you haven’t missed anything. Both the general risk-based approach as well as the specific controls-based approach are useful for understanding how auditors evaluate IT security programs at regulated organizations.

Another large regulated sector is publicly traded companies that fall under the Sarbanes-Oxley Act of 2002 (SOX). Congress passed this law to prevent another Enron-like defrauding of investors. SOX has many requirements around transparency and conflict of interest, but there are special rules relevant to IT security as well. SOX requires companies to establish security controls around financial and messaging systems to protect their availability and integrity. E-mail is considered relevant to SOX because of its prominence in the Enron case. Because of the regulation involved, SOX requires an independent audit of these controls. SOX does not call out specific security technologies or tools, but is risk-based, like GLBA. Large banks are often publicly traded companies, so they find themselves under both GLBA and SOX audits.

The third-largest regulated sector is the medical health sector, covered primarily by the Health Information Technology for Economic and Clinical Health Act (HITECH) and the Health Insurance Portability and Accountability Act (HIPAA) . These acts have strict security requirements for hospitals, health care clearinghouses, and health care providers (referred to as covered entities) to protect the privacy and integrity of patients’ electronic personal health information (EPHI) . Like GLBA and SOX, HIPAA is not specific about technology but does require that organizations perform a risk analysis and build appropriate risk management processes. Be aware that medical information (and the accompanying security/audit requirement) can spread far beyond hospitals and cover individuals and organizations that do any kind of data processing on health records, including health insurance, medical billing, or medical data analysis organizations. Most of these organizations must undergo a HIPAA security audit, either directly or indirectly.

Regulated Industries Without Explicit Audits

Speaking of health records, a smaller but important regulated sector is drug and medical device companies. If a medical treatment is going to get FDA approval, the IT systems involved in drug development, medical device manufacture, or testing require exacting security controls to guarantee the integrity of the medical records. This is covered by Title 21 of the Code of Federal Regulations (21 CFR Part 11) under Electronic Records. It has additional IT security requirements around electronic signatures, which is rare in other industries. There are no formal audit regimes for 21 CFR Part 11, but the FDA does review the controls and records as part of the approval process. Although there is no specific audit requirement, after-the-fact investigations after incidents are as rigorous as any audit.

Another regulated industry that does not require a formal audit covers companies that collect personal information on children under the age of 13. Congress passed the Children’s Online Privacy Protection Act (COPPA) to protect children’s privacy on commercial children’s online services (web and mobile). In addition to rules around parental consent and disclosure, operators must have security measures in place to protect the confidentiality and integrity of the information they collect from children. Although COPPA doesn’t require an audit yet, because of the considerable industry penalties involved, an internal audit is a good idea.

Companies that manufacture, store, or distribute hazardous or critical chemicals also have security requirements that include addressing IT security risks and physical threats under Chemical Facility Anti-Terrorism Standards (CFATS) regulation. Presidential Policy Directives consider a chemical facilities’ critical infrastructure, and therefore companies need to ensure the security of any toxic, explosive, or vital chemical. No explicit regular audit of IT security systems is required yet.

Business Transactions Can Loop You into an Audit

Although the payment card industry is not a government-regulated industry, an enormous number of organizations, both private and public, accept credit or debit cards (payment cards) as a means of payment. The issuers of payment cards created a council, the Payment Card Industry Council, to develop a set of strict requirements, called the Payment Card Industry Data Security Standard (PCI DSS) . The PCI DSS has over a hundred specific control requirements under the umbrella of twelve major control objectives. PCI DSS is not flexible and mandates specific risk treatments based on the common threats to the average payment card processor. Depending on the volume of transactions in the operation, PCI DSS can require an audit. This book covers the analysis and selection of controls that lead you to the required controls for PCI DSS.

If a business provides services on behalf of an organization in a regulated industry, then it can be subject to an indirect third-party audit based on those regulations. For example, companies that store or process payment cards on behalf of other companies are subject to PCI DSS requirements. Companies that supply software or services to financial firms can find their customers requiring them to be audited against GLBA requirements. Service providers that involve critical financial transactions of publicly traded companies need to adhere to SOX regulations. The federal government also tasks medical third parties with security requirements. Per HIPAA regulations, all business associates are contractually required to agree to have appropriate security controls in place and can be subject to audit. This requirement contractually flows downstream, so any suppliers of the third party that have contact with confidential medical data also fall under these requirements. The HITECH law now requires periodic HIPAA audits of both covered entities and their business associates.

Does your organization do any business in Massachusetts that involves collecting and storing customer or employee personal data? Massachusetts General Law Chapter 93H and the 201 CMR 17.00 statutes (a.k.a. Mass Data Protection Law) cover the protection of the personal data for any Massachusetts resident. The law spells out a list of security controls that must be in place. While not specifying an audit, it would be a good idea to check your program to ensure that it’s compliant and functional. If something does go wrong, it always helps to demonstrate diligence and transparency by having a previous audit done.

Even if your customers don’t have explicit regulatory requirements, they may still require that their suppliers with access to confidential data be secure. For example, law firms, consulting companies, and software contractors have found themselves under contractual security mandates from their clients because of the sensitive data they handle. It’s becoming common for service contracts to include a “right to audit” clause with penalties for nonconformance.

A Lawsuit May Drag You into Something Worse Than an Audit

If an organization has e-mail or internal electronic communication, any kind of lawsuit can create e-discovery issues as plaintiffs seek out digital information related to their legal complaint. Under the Federal Rules of Civil Procedure (FRCP) , companies must take measures to prevent tampering with subpoenaed data, referred to as spoliation of evidence. Judges can require proof of these measures if witnesses do not provide timely and complete data subpoena requests. If that information is not secure and available, this could trigger a prolonged and punitive investigation of an organization’s IT messaging and storage systems. This kind of legal investigation can become far more invasive and adversarial than any audit. Findings of spoliation can lead to financial penalties and/or adverse findings in the case.

The worst kinds of lawsuits for IT security are the ones from customers accusing an organization of negligence in protecting their data. When things do go wrong, audits demonstrate your due diligence. Suppose a hack does happen: you can point to a thorough and timely audit as your organization’s commitment to pre-empt problems. A self-regulating organization with an eye to testing and improving its security is in a much better position to defend itself legally and in public. In negligence cases, judges look favorably on a healthy security program backed up by an independent audit, and hacks appear more like bad luck than willful ignorance or IT penny-pinching.

Business-to-Business Audits

Depending on your industry, just the act of soliciting large and important customers can bring about an external review of your IT security program. Some industries, like finance and government, have security assessments built into their request for proposal (RFP) process. So you can easily find your own sales team leading customer prospects into the security team’s office to answer questions. In those situations, it’s always great to be able to pull out a recently completed audit report and hand it to them for review.

Sometimes the act of working with a new business partner or supplier entails an audit. For example, some credit reporting bureaus require security assessments of their customers to ensure that they are protecting the confidential information accessed through their service. It seems strange that a vendor would add security responsibilities on top of the payment that you’re already making for their service, but that is what happens if the data is sensitive.

When companies are acquired, the purchasing entity sometimes conducts an audit of the IT systems as well. Many smaller companies do not have as robust and detailed a security program as their larger acquirer. This kind of audit can be one with dire consequences—especially if the staff of the acquired entity does not make the grade of the new parent company.

If an organization is seeking IT security insurance to assuage the damages that come from breaches and cyber-attacks, then they need to submit to some kind of security audit from the insurer. No insurance company wants to cover an organization for a loss without having some idea of their risk exposure.

Will/Should You Audit Your IT Security Controls ?

Does your organization…

• Collect, store, or process financial transactions?

• Do business as a publicly traded company?

• Collect, store, or process payment cards?

• Collect, store, or process health or health insurance information?

• Collect, use, or disclose data on children under the age of 13 years?

• Develop, manufacture, or distribute FDA-approved drugs or medical devices?

• Manufacture, store, or distribute dangerous or important chemicals?

• Act as a service provider with access to customers’ confidential data or to critical systems?

• Create and store electronic messages that could be subpoenaed as part of a criminal or civil investigation?

• Collect, store, or process personal information on citizens of Massachusetts?

The Burden of Audit Is on You

In an audit, there is no presumption of innocence. An auditor will not ever assume that you are compliant. Instead, auditors assume that what they haven’t tested yet is insecure. The burden is on your organization to prove to outsiders that you are compliant. This means that even if you think you’re compliant, if you cannot produce the timely, accurate, and complete records as proof, then you may have problems. It is best to prepare ahead of time.

Aim Higher Than Compliance

It is a waste of resources to build an IT security program solely devoted to meeting a compliance requirement. It is true that some organizations just want to check the audit check box and move on. Many companies coast this way for years. By blindly implementing controls to meet compliance requirements, you are in danger of having an inefficient and ineffective security program. Compliance requirements are the result of negotiation and committee work, which means weak and delayed standards with incomplete coverage. New threats and technology always leapfrogs what regulation defines as necessary, especially if that regulation spells out specific controls or technologies. Building a security program just to meet compliance falls short of addressing the current risks your organization faces. Ultimately, that is the goal of a security program: reduce risk, not pass audit.

If you are going to the trouble of building an IT security program and have it pass audit, you should at least make sure that your security program is useful for your organization. Security controls are expensive—directly in the cost of technology and indirectly in the cost to people’s time and convenience in running through them. Think of TSA airport security with all its backscatter imaging systems, guards, X-ray machines, metal detectors and long, long lines. If you’re going to do all of that, why not make the controls actually effective and appropriate to your organization’s business? Most audit requirements are designed for a typical organization with typical risks. Your organization isn’t typical in at least the one aspect that makes it unique and valuable. The IT security program should consider this and not adopt a one-size-fits-all control regime.

Audits Make You Look Good

An audit with no significant findings is a worthy accomplishment. Your organization can issue a press release or send an announcement to all of your customers about these kinds of achievements. Sales departments are always looking for reasons to contact customers with good news. Besides reassuring customers that their data and transactions will remain undisclosed and untouched, audits demonstrate your ongoing commitment to privacy and security. By proactively seeking out and passing an audit, you show the world that your organization puts its money where its mouth is. You can work with marketing on delivering an ongoing campaign, extolling the trust and confidence that comes with industry audit certifications . Smart customers realize that passing an audit requires an organization to expend serious resources on IT systems. Audits may not always tell you if an organization is secure enough, but they will at least weed out the lazy and the ignorant. Like peacock feathers, a passed audit is a good indicator of health and strength.

The Audit as a Forcing Function

Audits are great motivators to build a security program. It is hard work to get a security program off the ground, much less in a semifunctional state to pass an audit. Left to their own devices, the IT department would rather focus on keeping the existing systems up and functional with a minimum amount of fuss. They are already busy patching, upgrading, adding capability, and helping users. Also, IT teams can be very protective of their systems. Changes, especially the large changes that the security programs sometimes require, can cause downtime or confuse the users. Their livelihood revolves around keeping things running. The last thing they have time to do is retool their systems because there is a possibility that a hacker might break in someday. However, an auditor is a real and present danger. Hackers are hiding somewhere out on the darknets and they may or may not bother to poke at your organization. The auditors are there in the office and in their faces, asking them hard questions. Even if they weren’t moved by risk of breach or failure, the IT department and the users know that they will be held accountable for a failed audit.

To pass an audit, an entire organization needs to coordinate, pay attention, and put effort toward getting controls and processes in place. An audit mandated by the executive suite sets a tone and direction for the entire organization to build an IT security program as part of the organizational culture. Audits also provide a tangible milestone for leadership to measure the success of the IT security program. With the audit looming, it is also easier to get budget and resource approvals for necessary controls and changes.

One of the hard things about being in the security field is that you are the person who tells everyone else “No!” No to that new business idea. No to relaxing the stringing password policies. No to hiring that great developer with a long police record. No to the flashy new web site full of vulnerable code. No, no, no. With an audit in place, the security team can now point elsewhere for the blame. “Sorry, I’d like to do that but I’m afraid we’d have an audit finding.” There is significant value in having a scapegoat for getting the unpleasant things done and denying the insecure requests.

ISO 27001

A striking thing about an ISO 27001 audit is its strong focus on the risk management process, with a weaker emphasis on using specific controls. The ISO 27001 audit requires the use of a classic management tool, the Deming Cycle (also known as the Deming Wheel, the PDSA Cycle, and the PDCA Cycle), which has four rolling phases: Plan (risk analysis), Do (risk mitigation), Check (internal audit), and Act (adjust controls). Organizations can select controls during the “Do” phase based on a pre-supplied list of best practice controls, but organizations can choose to skip controls in the list if they can provide sufficient justification for exclusion. Organizations are also encouraged under ISO standards to add new controls to ensure that they are adequately managing all risks. ISO 27001 audits also require organizations to identify and document a formal method of risk analysis.

ISO 27001 calls the IT security program the information security management system (ISMS) . The ISMS must have certain standard features and roles, as defined in the standard. In general, ISO 27001 audits require more paperwork than any other audit. There is a strong emphasis on policy, procedures, and the creation of records related to the running of the ISMS.

The SSAE 16

The SSAE 16 actually has three types, called Service Organization Controls (SOC) , and numbered 1 through 3. The SOC 1 audit is the most flexible in terms of control design. Yes, you still need to do a risk analysis, but what the auditor actually reviews are your control objectives and the controls supporting those objectives. The risk analysis focuses on protecting the systems involved in performing financial transactions and messaging. This audit satisfies SOX. The SOC 1 is issued by the American Institute of Certified Public Accountants (AICPA) . The predecessor of the SSAE 16 SOC 1 was the Statement on Auditing Standards No. 70, or SAS 70. Some individuals still refer to the SSAE 16 SOC 1 as a “SAS 70” type audit, even though the standard has evolved.

The SOC 1 works with the audited party (you) writing control objectives (with some auditor’s help) that mitigate the risks identified against financial transaction integrity. For example, a control objective would be written, “Controls will provide reasonable assurance that Electronic Access to Systems is appropriately restricted to authorized individuals.” Then, you would select controls like passwords and firewalls to support this control objective. Unlike the ISO 27001, for a SOC 1, there are no pre-defined controls or objectives to pick from; you need to create your own based on the relevant systems and risks.

This changes when we move to SSAE 16 SOC 2. In a SOC 2, there are pre-defined control objectives and general control descriptions. As part of your audit scope, you can choose what SOC 2 control objectives you’d want to certify. The choices are Security, Confidentiality, Processing Integrity, Availability, and Privacy. Be aware that the Privacy objective is more business-process focused than security-focused and not covered in this book. For these control objectives, SOC 2 specifies controls through Trust Service Principles that must be in place to manage certain kinds of risk. This audit is a bit more specific with respect to certain kinds of controls, as opposed to the SOC 1. Overall, this is to make the audit more standardized (you either have this control in place or not) and easier for people to implement. It does come at the cost of the flexibility for the organization. The SSAE 16 SOC 3 audit is the same as a SOC 2, except the organization can make the audit certificate publicly available, whereas SOC 1 and SOC 2 audit reports are restricted to other auditors’ review.

In an SSAE 16 audit, there are two explicit types, also numbered. A SSAE 16 Type 1 audit is a design audit, with a single visit to review the design of the controls and control objectives. Functionality and operational effectiveness are not measured. A SSAE 16 Type 2 audit is a performance audit that covers a three-to-twelve month period, with the auditor visiting several times during that period to examine how well controls actually work.

PCI DSS

The most restrictive type of audit in terms of control choice is PCI. Under PCI DSS, you must implement all the controls as described. Skip a control or implement it inadequately and you do not meet the standard. With ISO and SSAE 16, you can leave out some controls—as long as the failures don’t jeopardize fulfilling the control objective and address risk adequately in the eyes of the auditor. The reason PCI DSS is far more restrictive is because it is centered on payment cards and payment card processing, which have well-known risks and well-understood IT systems. Therefore, PCI DSS can skip over some of the risk analysis and scoping exercise needed for other types of audits, and focus on the controls that the PCI council believes works the best to protect payment cards. Since systems processing payment cards are so widespread (think of all the e-commerce sites), there needs to be a cut-and-dried way to evaluate their security posture. Assessing against a list of controls goes a lot faster than having an auditor try to interpret a risk analysis and customized control objectives. It also requires less expertise on the part of the control implementer and the auditor.

Another difference between these audits is how frequently the auditor reviews the running controls. For PCI, the auditor performs a single comprehensive audit once per year. For ISO 27001, the auditor returns every six months to recheck the controls and the health of the IT security program. The ISO 27001 has some discretion in the frequency, based on stability of the environment and the strength of the controls.

Auditors Auditing

How do auditors perform an audit? There are several levels of investigation, depending on the importance and functionality of the control. The simplest form of evidence gathering is attestation: they ask you if something is true or not. Auditors can expand this into testimonials by asking many people in an organization and seeing if their answers line up. This actually works well. If an auditor asks three people about “the security policy around laptops in cars” and gets three different answers, then the so-called policy is not actually a company policy. For critical or technical controls, auditors will look for physical evidence. Audit teams gather this evidence by either direct inspection or by requesting copies of records and screenshots. Auditors usually do not ask for every single record, but use statistical sampling with confidence intervals to get a measure on things. In some cases, auditors may in fact look at every single record, especially if the majority of the samples are coming up negative. Auditors perform some of this work on-site, but can also work off-site as well. All formal audits mentioned here require at least one site visit to do physical inspection, with the exception of PCI DSS level 4, which allows self-reporting for low-volume payment card merchants.