After ruminating on this a bit I think it's sufficiently "sysadmin-related" to warrant an actual answer - system administrators have the joy of being exposed to a variety of industry auditing standards (SAS/SSAE, PCI, ISO, and countless others) and a good general answer on how to handle audits is something we're lacking, so here's my attempt at one.
TL;DR version:
- Get yourself a copy of the applicable standards
- READ the standards.
- UNDERSTAND the standards.
- Ensure that your company's policies and procedures meet the requirements.
- Ensure that your company follows its policies and procedures.
- Enjoy your no-sweat audit.
Material specific to SSAE 16 will be offset like this.
Note that SSAE 16, like the SAS 70 statements its replacing, isn't really a "standard" - it's a statement by AICPA on how an audit is to be conducted and how results are to be presented.
The SSAE 16 audit itself is still very much a "The company does what their procedures, contracts, etc. say they do" audit. It's often trotted out like an "auditing bogeyman", but it's really not that scary, and imposes very few requirements in-and-of itself.
What is an audit anyway?
Wikipedia has a great definition of an Audit: an evaluation of a person, organization, system, process, enterprise, project or product.
In the context we're most often involved with them, audits are designed to ensure that an organization's processes and procedures meet certain control objectives - for example ensuring that only authorized users can make changes to a firewall's configuration.
Sounds simple enough… So what are they going to look at?
If an audit is conducted properly everything that is going to be covered in the audit will be detailed in the standard you're being audited against. If you review the standard you know what's going to be looked at, and you can conduct your own internal reviews and audits to ensure you're in compliance before an external ("certification") audit takes place.
In the case of SSAE 16 the Statements on Standards for Attestation Engagements (SSAE) is promulgated by the American Institute of CPAs. It is one of several free standards documents you can obtain from them.
This all sounds swell, but why is IT involved?
Name one aspect of the business IT doesn't touch.
Many, if not most controls that get implemented have some technical underpinnings (like "Users log in with a username and password") for which the technical staff is ultimately responsible.
OK, What do I need to prepare for an audit?
Generally you need two things to prepare for any audit:
- The standards document you are being audited against.
This is really Item Zero of any audit: The auditor must verify that your company is in possession of the current revision of the standards document.
This is sometimes overlooked by the auditor, but it's to your detriment if you're trying to comply with a standard you haven't read and can't refer to.
- A reasonable quantity of common sense.
You are going to need to read the standards document and either
- Map each requirement of the standard to an existing process, procedure, or control; or
- Create a new process, procedure or control to satisfy the requirement.
This still doesn't sound so terrible. Why do people hate audits?
There are two common reasons people dislike auditing (aside from the inherent loss of productivity during the audit itself): Bad Preparation, or Bad Auditors.
Bad Preparation - or "How to ensure a miserable audit experience."
Many people have tales of auditing woe - "It was supposed to take a day and they beat us up for two weeks!". I have no statistical data to back me up, but anecdotally most of these stories I've heard can be traced back to poor preparation on the part of the organization being audited.
Either through ignorance, laziness, or resource constraints the organization is failing to meet one or more of their defined control objectives (or the requirements of the standard), and the auditor is doing their job by smacking the organization upside the head and saying they screwed up.
As an example, if a standard requires that you prevent unauthorized users from modifying production systems one way to accomplish this is to give all of your administrators a shared username/password, known only to the administrative team.
This certainly meets that requirement, though any sysadmin would say it's pretty bogus, but if you're lazy or in a hurry you might implement this solution.
If you read further in the standard you'll probably uncover another clause that says something like "configuration changes on production machines must be logged, including the date, time, and person making the change" -- suddenly your shared password scheme doesn't work anymore: You need individually traceable identification and authentication, and if you had read the standard (or thought the requirements through and used that common sense I mentioned earlier) you would have known that.
You'll see an example of an auditor calling out poor preparation in Appendix B of SSAE 16 section 801, an excerpt from a sample audit report which reads as follows:
The accompanying description states on page [mn] that XYZ Service Organization uses operator identification numbers and passwords to prevent unauthorized access to the system. Based on inquiries of staff personnel and observation of activities, we have determined that operator identification numbers and passwords are employed in applications A and B but are not required to access the system in applications C and D.
Bad Auditors - or "I don't know why, I was just told you need to do X!"
The other end of the spectrum also happens - auditors are very often not experts in all areas they're auditing. They are almost certainly familiar with the standards (if they're not ask for another auditor!), but the specific application of the standard may be beyond their realm of expertise.
An auditor does not have to be a system administrator to know if a control objective like Usernames and passwords are employed as an access control mechanism for XYZ Application -- They can watch a few people use the system and verify that each person enters a username and password.
Bad Auditors are the ones who don't understand that there may be many ways to achieve a control objective (for example, using smartcards instead of usernames and passwords to log in), or worse auditors who simply don't understand the reasoning behind the standards they're auditing against.
Typically all you can do here is disagree with the auditor's opinion (take the issue to their boss, either with evidence that you are meeting the requirements that the auditor claims you aren't or with evidence that shows the auditor's request is out of scope or would in itself be a violation of the standard for you to fulfill).
"Failing" an audit
There are a couple of ways to "fail" an audit, and some are better than others.
That rarely happens, and you shouldn't expect it. Every audit is going to find some issue to poke at. These go by a lot of different names - "Audit Exceptions", "Non-Conformance Notes", and "Violation" being pretty common ones - but just because there's a negative finding doesn't always mean you've "failed" an audit.
Audits for certification are typically done against a standard that has certain performance requirements (perhaps the best known example is the ISO 9000 series of Quality Management standards). Completion of the audit results in the auditing team making a recommendation to a certification body to certify (or not certify, or de-certify) an organization as "in compliance" with a given standard.
Minor deficiencies in performance may not hinder certification.
For example ISO 9001 requires that a company establish periodic reviews of quality data. If a company states that a quality review of their manufacturing line is conducted every 30 days but in reality they do it the first of every month they are technically not in compliance with their procedures, and thus by the strictest possible application they can't be certified.
What typically happens in cases like this is the auditor issues a non-conformance notice and recommends certification "pending acceptable corrective action on all non-conformance notices". The company then changes their operating procedures manual to say "Monthly quality review", sends a copy to the auditor, and gets certified.
Larger non-conformances ("You say you read and respond to all customer complaints within 30 days, but I saw you taking the big mail bag full of complaints and burning them in the parking lot without even opening the bag!") are pretty much a guaranteed failure -- these are things that show an organizational culture of disregarding the applicable standards/requirements.
This sort of thing generally requires a full re-audit to prove to the auditor you're taking the requirements seriously.
Remember, auditors are accountable to someone else too -- usually a certification body.
If their audits are questionable they will eventually lose the authority to conduct them.
Audits under SSAE 16 (SAS 70) are "We do what we say" audits.
You can't "fail" the audit because the standards are your own, but you can have "material non-conformances" (which is fancy AICPA/Auditor speak for "You failed because you don't do what you say you do!").
For little things like the sample paragraph I quoted earlier, fixing the affected systems C and D to require passwords and submitting proof to the auditor may be enough to get an amended audit report issued showing that a material non-conformance has been addressed, but as with audits for certification against a specific standard if the auditors get a sense of an "organizational culture" of disregard for the rules/requirements it will be much harder to get them to agree to reissue their report without a full re-audit.
