Regulatory Compliance, Governance and Security

March 20, 2009  6:34 PM

SAS 70 Compliant | Discussion on SAS 70 Auditing Methodologies


Being SAS 70 compliant is quickly becoming a requirement for many service organizations (i.e., companies that provide outsourcing to another entity) in today’s business arena. Many companies, however, voice frustration in not really understanding the audit methodology used and the process/roadmap for becoming SAS 70 compliant.

Let me distill some of these issues for you in better helping understand the auditing standard.

First and foremost, auditors who conduct SAS 70 audits use standards put forth by the AICPA and other approved governing bodies and “best of breed” corporate governance institutions (i.e. ISACA, IAA, etc.)

Additionally, what you need to know is that their is a commonly used “Roadmap” for SAS 70 compliance that consists of these sequential steps:

1. SAS 70 Readiness Assessment: Activities necessary for understanding your organization’s control environment, the scope of the audit and other essential areas.

2. Remediation: These are activities needed for becoming SAS 70 compliant. Generally, they include strengthening one’s control environment by utilizing any number of measures (additional security controls, policies and procedures, etc.)

3. Document Gathering: After steps 1 and 2 are completed, auditors need to gather documentation for the audit. This is a collaborative process that includes the auditor and the service organization undergoing the audit. This can take some time.

5. Fieldwork: Auditors will then arrive on-site to conduct fieldwork activities necessary for testing your internal controls in accordance with SAS 70 auditing standards.

6. Outcome of testing/drafting of report/discussion of findings: These are all activities that occur subsequent to fieldwork.

As one can see, being SAS 70 compliant requires the initiation of a number of steps for the audit process.

To learn more about SAS 70 audits, visit the official SAS 70 Resource Guide.

March 20, 2009  6:20 PM

SAS 70 Compliance | Tips on Scoping a SAS 70 Audit


SAS 70 compliance is commonplace for many of today’s businesses. Unfortunately, one of the missing ingredients in understanding SAS 70 compliance is the scope of the audit. That’s right. The who, what, when, where, and why of the actual SAS 70 audit process. Most service organizations undergoing a SAS 70 audit think that they are all the same, that is, one SAS 70 report should “look and feel” like another report. This is incorrect, as different industries and companies alike have varying requirements on what needs to be covered for SAS 70 compliance.

Here are some things you need to know to help determine SAS 70 scope:

1. What is the test period (if a SAS 70 Type II audit is being conducted)
2. Where are all the locations (physical offices, data centers) that will be included in the testing of the audit.
3. What is the audit actually COVERING? That is, is it a general controls audit or are their certain business processes that are being included in the scope of the audit? (This is essentially one of the biggest scoping issues you need to understand and come to an agreement on).

To learn more about SAS 70 compliance and scoping, visit the official SAS 70 Resource Guide.

March 15, 2009  2:24 AM

SAS 70 Type 2 Audit | Learn about SAS 70 Compliance


If you want to learn more about a SAS 70 Type 2 audit and SAS 70 compliance, then listen up. Becoming SAS 70 compliant can be full of minefields out in today’s regulatory compliance world. But it shouldn’t be. In fact achieving SAS 70 compliance should be looked upon as a structured, multi-step process where you live and learn each and every step of the way about compliance. Sure, there may be horror stories out there about the time, costs, and pain in becoming compliant, especially for a SAS 70 Type 2 audit.

So, let’s distill fact from fiction in helping you learn the nuts and bolts about statement on auditing standards number 70.

First, you need to gaining a strong understanding of what SAS 70 is, what internal controls are, what control objective are, amongst other things. But how? There are a couple of ways: the AICPA publishes excellent, technical reference manuals on SAS 70. Though written more for the auditor in mind, they can still help you greatly understand SAS 70 compliance.

Second, visit the official SAS 70 resource guide, where an abundance of use information awaits you.

Some tips on saving money on SAS 70 compliance? Whoever conducts the audit, ask for a free readiness assessment and also ask for a Fixed fee for the audit. If you can get both of these, you are on your way.

March 14, 2009  10:35 PM

SAS 70 Certification | Learn about SAS 70 Type 2 Audits


SAS 70 certification is becoming a hot topic for many organizations in today’s business world. You name the industry, and i can almost guarantee you that somebody has had to be SAS 70 compliant. Though the term SAS 70 certification is technically incorrect, because you are not really becoming “certified”, rather, you are becoming compliant. Not a big issue, just wanted to clear up a technicality that I hear quite a bit about.

So, back to SAS 70 “certification”. What you need to know is that it is a multi-step process which includes the following phases:

1. SAS 70 Readiness Assessment
2. Remediation for anything uncovered during the Readiness Assessment
3. On to the audit-That is, fieldwork for a SAS 70 Type I or Type II.
4. Findings from the auditor and drafting of the report
5. Issuing the report, which is technically called a “SAS 70 Service Auditor’s Report”

These are steps to follow in becoming SAS 70 compliant. It is the most logical, transparent, and efficient process you will find.

Visit the official SAS 70 Resource Guide
to learn more about SAS 70 certification.

February 23, 2009  5:13 PM

SAS 70 Internal Controls | Important Facts and Tips to Know


SAS 70 audits test a wide array of internal controls within your organization for helping ensure SAS 70 Type I or Type II compliance. What’s interesting to note about these “internal controls” is that you need to truly understand what they are and how they relate to the “control objectives” being tested for during the SAS 70 audit.

Technically speaking, internal controls are: A process, affected by an entity’s board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in various categories.

In more simpler terms, internal controls for SAS 70 audits can be best viewed as the processes, procedures, and related activities that YOUR organization has in place for ensuring that a structured, safe, sound, and secure “control environment’ is in place. In short, is your organization dotting your I’s and crossing your T’s when it comes to daily operations within your organization.

Now, there are a “best of breed” agreed up control objectives and related internal controls that should be used for SAS 70 audits, which you obtain from a quality CPA firm specializing in SAS 70 audits.

However, not all CPA firms use the same control objectives and technically, its really up to the organization undergoing the SAS 70 to actually construct, develop, and agree upon what there internal controls and control objectives would be. In reality, good quality CPA firms can help you with this. It’s really a colloborative process, to say the least, regarding SAS 70 internal controls.

February 23, 2009  1:32 AM

PCI Policy and Procedures Documents | You Need them for PCI DSS


PCI policy and procedures documents are extremely critical in achieving Payment Card Industry (PCI) compliance. How critical? Enough that an entire requirement for PCI is dedicated to developing an information security program. In fact, requirement 12: Maintain a policy that addresses information security for employees and contractors, requires just that, developing these policies and procedures.

But hold on, it is much more than just PCI DSS Requirement 12; there are a number of other areas sprinkled throughout the PCI DSS requirement that “require” documented policies and procedures on a wide array of items. News to you? Maybe, maybe not. Either way, writing these PCI policy and procedures documents take time, alot of time.

Add to the fact that because every organization is different, you can not simply stamp on a one size fits all approach; it does not work that way. You need to spend time customizing the policy and procedures document so they fit your organization’s needs.

Sure, you can start with some broad based themes and templates, but you will really have to roll your sleeves up to grind out the details in achieving the true “spirit” of these documents.

February 23, 2009  1:11 AM

What is SAS 70 | A Question I’m Often Asked by Service Organizations


What is SAS 70? For us in the regulatory compliance and Information Technology world, this would be an absurd question. Well, put yourself in the shoes of businesses who work hard everyday, struggling to make ends meet, and then suddenly, they’ve been told they need a SAS 70. A SAS what? I field these calls everyday from the curious minded individuals who have now come to find themselves locked into the regulatory compliance game that many service organizations have come accustomed to.

So, then. What is SAS 70? Well, its an auditing standard put forth the American Institute of Certified Public Accountants (AICPA) in 1992, which is used to report on controls placed in operation and (if need be), tests of operating effectiveness. English please, right? Okay, in more simpler terms, its an audit that is used to test a number of controls (i.e., “checks and balances” you should have in place) throughout your organization.

To add to this, there are TWO types of SAS 70 audits; a Type I and a Type II. Most organizations having to comply with and go through a SAS 70 audit ultimately prepare for a SAS 70 Type II audit.

Okay, these are the basics, to learn more, visit the official SAS 70 Resource Guide, where you can learn all you need to know about SAS 70 audits to help answer that ever important question-What is SAS 70?

February 21, 2009  12:57 PM

PCI Requirement 1: Install and Maintain a Firewall Configuration to Protect Cardholder Data | What You Need to Know


For Payment Card Industry (PCI) compliance, there are twelve (12) core, functional requirements mandated under PCI DSS v1.2. What’s important to note is that many times you truly need to “read between the lines” to interpret, comprehend, and understand what the PCI DSS standards are actually stating, and asking you to validate.

Take PCI Requirement #1: Install and maintain a firewall configuration to protect cardholder data. If you read all the requirements and the tests that accompany each requirement, it seems to sound quite straight forward. Well it is and it isn’t. The “isn’t” part lies in the ability to interpret some testing that really has not been spelled out for you. For example, throughout requirement #1 it tells you to “examine” and “verify” a whole host of configuration settings for network devices, particularly firewalls and routers. So how should you interpret “examine” and “verify”. As a Qualified Security Assessor (QSA) for PCI, I can tell you that just simply asking for the rulesets and configuration documents is simply not enough. You have to actually examine, interpret, read, and dissect the rules and configurations settings, match them against the test criteria, along with using the network topology documents (that should be developed) as further evidence. In short, simply printing out rulesets, throwing them in a folder as audit evidence and moving on to the next phase of the PCI is not going to cut it. If you want to brush on truly understanding rulesets and the configuration of network devices (routers, firewalls, load balancers, etc.), CISCO and JUNIPER and other network device providers have a host of free information on the internet.

To learn more about PCI DSS compliance and Requirement 1 and other areas of the PCI DSS v.1.2 standard, then visit

February 18, 2009  7:53 PM

PCI DSS and SAS 70 Audits | Audit Efficiencies? Maybe…just Maybe


As a SAS 70 auditor and a PCI QSA, i’m often asked about the efficiencies of scale that can be achieved with SAS 70 audits and PCI DSS assessments. I have blogged about this a few times before, so let me be more clear and transparent in what i believe can actually be obtained in regards to audit efficiencies when conducting a SAS 70 and a PCI DSS assessment on an entity.

First and foremost, as an auditor, there should still be independence within the SAS 70 audit and the PCI DSS assessment. Independence how? Simple, do not treat them as one audit, because they are simply not that. Technically speaking, a PCI assessment is just that, an assessment, not an audit, which requires “attestation”. Moreover, there are significant differences between the audit and the assessment, which can be discussed at length (and will be) in a whole different blog.

I stress in the title of this blog that “maybe” there can be audit efficiencies, however, it many times is dependent on the quality of the auditors, their expertise in both conducting a PCI and a SAS 70 audit, and how much they are willing to rely on evidence from the PCI DSS assessment for the SAS 70 audit, and vice versa. Good auditors will find ways to create these efficiencies; other auditors might want to conduct a PCI DSS assessment and rubber stamp a SAS 70-this is a BIG NO NO.

Want to learn more about where these efficiencies of scale can be maximized? To learn more about SAS 70 audits, visit the official SAS 70 Resource Guide and to learn more about PCI DSS Assessments, visit the PCI Resource Guide.

February 14, 2009  1:52 PM

Payment Card Industry (PCI) Compliance | Much More than just I.T.


That’s right. Payment Card Industry (PCI) compliance is much more than just I.T. and all the surrounding hardware and software components that make up the “system components” within the cardholder environment. I’ve just recently finished up a PCI Readiness Assessment for a client on the West Coast and guess what happens to be there most significant and time consuming remediation activity? The writing of documented policies and procedures for numerous requirements as set forth and promulgated by the PCI DSS v.1.2 standards. That’s right, they can be painstaking, arduous, and time consuming. Even worse, most I.T. security professionals really do not like to consume themselves with this daunting task.

So remember, when you are are all caught up in the PCI game and you are so focused on routers, switches, load balancers, and other network and system devices, make sure you focus on the much needed policies and procedures that are sprinkled throughout the PCI DSS requirements. My advice, hire a seasoned Qualified Security Assessor (QSA) to write them for you, you’ll be glad you did.

And if you don’t believe me, take a look at Requirement 12: Maintain a Policy that Addresses Information Security.

To learn more about Payment Card Industry (PCI) compliance, visit

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: