COSO is a widely used and accepted internal control framework in today’s growing corporate governance initiatives. It’s also heavily found in Statement on Auditing Standards No. 70 (SAS 70) audits.
The Committee of Sponsoring Organizations of the Treadway Commission (COSO) framework essentially defines internal control as a process, effected by an entity’s board of directors, management and other personnel. This process is designed to provide reasonable assurance regarding the achievement of objectives in effectiveness and efficiency of operations, reliability of financial reporting, and compliance with applicable laws and regulations.
1. Internal control is a process. It is a means to an end, not an end in itself.
2. Internal control is not merely documented by policy manuals and forms. Rather, it is put in by people at every level of an organization.
3. Internal control can provide only reasonable assurance, not absolute assurance, to an entity’s management and board.
4. Internal control is geared to the achievement of objectives in one or more separate but overlapping categories.
What’s notable about the relationship with COSO and SAS 70 are COSO’s framework for internal control, which consists of the following five (5) broad based themes:
1. Control Environment
2. Control Activities
3. Risk Assessment
4. Information and Communication
Many SAS 70 Type I and Type II audit reports will discuss, in narrative form, these above five areas and how they relate to the organization undergoing the SAS 70 audit and what specific controls they have in place in relation to these five areas.
And let’s not forget the Statement on Auditing Standards (SAS pronouncements) that help bring these five internal control themes to light.
In 1988, the American Institute of Certified Public Accountants (AICPA) issued SAS 55, which describes internal control in terms of its three major components: control environment, accounting system, and control procedures. Shortly thereafter, the Committee of Sponsoring Organizations (COSO) released the following: Internal Control: Integrated Framework, in which internal control was characterized as five components: control environment, control activities, risk assessment, information and communication, and monitoring.
Thus, in 1995, the AICPA adopted COSO’s definition and it’s five components of internal control, issuing SAS No. 78 to supplement SAS No. 55.
So, you should be able to now clearly see the relationship with SAS 70 and COSO and the relationship with SAS 70 and other SAS pronouncements, specifically, SAS 55 and SAS 78.
If you want to learn more about SAS 70 audits, visit the official SAS 70 Resource Guide.
PCI DSS Self Assessment questionnaires are used for the large and growing number of merchants who must comply with the Payment Card Industry Data Security Standards (PCI DSS). In short, compliance can be obtained by conducting a “Self Assessment”. What’s important to note, however, is that there are five (5) different PCI DSS self assessment questionnaires.
Many merchants think that they can simply go through the questionnaires in a quick, one shot manner, and before you know it-they are compliant.
Unfortunately, it is not that easy as there can be a number of components that can cause hiccups in the PCI DSS self assessment process. First and foremost, merchants need to have documented policies and procedures for PCI DSS compliance. Writing these documented policies and procedures can be an arduous undertaking, to say the least. Additionally, there are numerous technology requirements that may be beyond the scope of a small merchant’s skill sets.
Talk to a PCI Qualified Security Assessor (QSA) to help you understand these issues and help give you clarity in becoming PCI DSS compliant.
Learn more about SAS 70 audits for data centers by reviewing the step by step SAS 70 audit process. From beginning to end, a number of steps, activities, and deliverables must be undertaken for ensuring the audit is successful. From the initial SAS70 readiness questionnaire assessments to the delivery of the final audit report, both the CPA firm conducting the audit and the data center employees will be working together in a collaborative manner for the audit.
Follow this step by step process if you are a data center or co-location facility that will be performing a SAS 70 audit in the near future:
First and foremost, identify the scope of the SAS 70 audit. Though it sounds quite straightforward, every CPA firm approaches scope in a slightly different manner. When identifying scope, there are a number of items to keep in mind, such as the following: Does the scope of the audit satisfy your client’s demands? Does the scope of the audit conform to industry accepted standards for SAS 70 audits on data centers?
Once the scope has been identified, it’s critical to begin the planning process with the auditors. A series of planning meetings should include a discussion on the following items:
1. SAS 70 readiness questionnaire assessment and when it will be done (if deemed necessary).
2. Discussion of type of sampling that is conducted for the audit (this is important as auditors have varying views on the numbers and amounts done on audit sampling).
3. Discussion that identifies key personnel involved in the audit from both sides.
4. Discussion on what data center physical security controls will be included in the scope of the audit.
These are just some general parameters to get you going in the right direction.
If you want to learn more about SAS 70 audits, then visit the official SAS 70 resource guide, where you can obtain SAS 70 sample reports for review.
SAS 70 Certification is everywhere these days, or so it seems. From small start-up organizations to large multi-national corporations, many people have been hit by the SAS 70 bug. What’s also interesting to note are the vast differences you can see when comparing two SAS 70 reports. In short, no two reports look the same. Is this a good thing or something wrong with the auditing industry? It’s actually a little bit of both, to be honest. The good thing is that it allows auditors to customize the reports as they see fit for the client. The bad thing is that many times a SAS 70 audit does not conform to an acceptable scope or standards of testing for control objectives.
Either way, what you need to know about SAS 70 Type I and Type II audits is that the SAS 70 certification process (and by the way, use the word “certification” is technically incorrect, as a SAS 70 audit does not certify anything, rather you have complied with the auditing standard, thus it should be called “SAS 70 compliant”) is highly flexible, this based in part on the rather “flexible” auditing standards that are in place. So, you need to properly identify the scope of the audit, and by doing so, you ensure that your organization ends up receiving a quality SAS 70 Service Auditor’s Report.
As for scope, you need to identify a number of parameters, such as:
1. Is my organization doing a Type I or a Type II?
2. If a Type II, what is the test period?
3. Are there any business processes or functions to be tested in the audit, or is it just a general controls SAS 70
4. Where are the physical locations that are included in the scope of the audit?
5. What third party outsourcing entities that my organization is using are to be considered part of the scope of the audit?
6. Has my organization developed control objectives that are considered acceptable for testing by the auditors?
To learn more about SAS 70 audits or to receive a free sample SAS 70 Type II audit in pdf format, visit the official SAS 70 Resource Guide.
SAS 70 compliance is a multi-phased, process based methodology that is undertaken by organizations seeking to become SAS 70 Type I or Type II compliant. As a SAS 70 auditor, I’m often asked what the SAS 70 audit process is, how long it takes, what are the “bumps” in the road that can occur. Thus, listed below are the major activities that must be enacted for ensuring your organization is on the right path to SAS 70 compliance.
1. Choose a CPA firm that provides SAS 70 services on a fixed fee, not an hourly basis.
2. Identify the SAS 70 audit that must be undertaken; either a Type I or a Type II audit.
3. If a Type II audit is your goal, identify the “test period” for the audit.
4. Discuss the scope of the audit, that is, what “business processes” are being covered and what physical locations will have to be a part of the testing process.
5. Begin a SAS 70 Readiness Assessment phase. This helps further identify the scope of the audit along with highlighting any weaknesses in your control environment.
6. If necessary, conduct remediation activities that were identified during the SAS 70 Readiness Assessment.
7. Once the above phases are complete, start to discuss fieldwork testing and the collection of documents for auditor that will be needed to help facilitate the audit.
8. Ask auditor for list of items that will need to be collected prior to the audit fieldwork.
9. Plan and prepare accordingly with the auditors for fieldwork.
10. Once fieldwork is complete, findings should be reported to you from the auditing firm, allowing you to give answers to any exceptions found during testing.
11. Drafting of report and final closing meeting to discuss report and finding ensues.
Visit the official SAS 70 Resource guide to learn more about SAS 70 compliance.
PCI DSS VISA Requirements for Merchants as stated by VISA require merchants to first and foremost identify what “Level” of compliance is required. This simply requires your organization to identify the number of transactions per year that are undertaken. In short, calculate or approximate this number to see which level you fall into.
Level 1: Any merchant-regardless of acceptance channel-processing over 6,000,000 Visa transactions per year and Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.
Level 2: Any merchant-regardless of acceptance channel-processing 1,000,000 to 6,000,000 Visa transactions per year.
Level 3: Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year.
Level 4: Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel-processing up to 1,000,000 Visa transactions per year.
Now, based on which Level you fall into, listed below are the requirements as set forth by VISA.
Level 1: Annual onsite review by QSA (PCI DSS Assessment) and Quarterly Network Scan by ASV
Level 2: Annual Self Assessment Questionnaire and Quarterly Network Scan by ASV
Level 3: Annual Self Assessment Questionnaire and Quarterly Network Scan by ASV
Level 4: Annual Self Assessment Questionnaire and Quarterly Network Scan by ASV
To learn more about PCI DSS Requirements, visit pciassessment.org
PCI DSS compliance is having a profound impact on businesses today. In short, the Payment Card Industry Data Security Standards (PCI DSS) is mandatory for any business involved in the processing, storage, or transmission of transaction data or cardholder data. As a result, this compliance requirement “should” be affecting millions of U.S. businesses. I say “should” because the lack of enforcement is resulting in a large number of organizations not complying with the PCI DSS standards. That could change as merchant processors and payment gateways are forced to have all their merchants comply with the standards. As a PCI-QSA assessor who conducts PCI DSS assessments, i’m starting to field many calls from merchants who have been contacted by their third party payment processor telling them they need to be PCI compliant.
I honestly think most merchants want to and will comply with PCI, but the “who, what, where, and why” of PCI DSS compliance can be quite vague at times. So, to be fair to merchants, some eduction is needed on this topic.
Thus, first and foremost, you will need to identify your transaction volume, that is, the number of transactions you undertake on a yearly basis for payment cards. This will help you identify what “level” of compliance you fall into. This handy reference guide for transaction volume will help you with this.
Once you’ve identified what “level” of compliance you fall into, you can then contact a PCI DSS specialist for helping assist in your compliance matters.
The whole new wave of I.T. spreading through businesses today is that of virtualization, cloud computing, the “cloud”, or any other similar and broad based terms or themes. Many people have hailed this new concept for obvious reasons, such as the reduction of overall hardware gear and space taken along with the ability to “virtualize” and share many common systems and applications via a centralized platform, just to name a few.
The challenge in this new I.T. arena is for auditors to truly understand what this new concept is and how they can apply new and improved auditing methods for ensuring that many popular assessment and audit initiatives (SAS 70 and PCI, just to name a few) remain viable. For example, both SAS 70 audits and PCI assessments rely heavily on “sampling” for testing. Sampling in a virtual world, though doable, will require truly understanding a virtual/cloud platform and how to logically isolate one customer’s system or environment from another customer.
In short, the old world auditing of having a single service or function residing on a dedicated, stand alone physical server box is, well, going to the grave very quickly. It’s time to roll up our sleeves and embrace the “cloud” and start to frame and shape improved audit procedures.
Sarbanes Oxley and SAS 70 audits have had a monumental impact on corporate governance and compliance. So much so, they almost invented a huge part of the pie. As a SAS 70 auditor, i’m often asked what does the future hold for Sarbanes Oxley (SOX) compliance and also SAS 70.
Well, my friends, let’s take a look at the crystal ball and let me give you my thoughts on SOX and SAS 70.
First and foremost, compliance is NOT going away. Sure, there have been growing pains with the cost and time associated with SOX compliance, but those costs are starting to become greatly streamlined as organizations are finding ways to be more efficient with SOX compliance. In short, it’s here to stay, so consider it a part of life in the business world. With the rash of fraud that occurred on Wall Street which almost toppled the capital markets overnight, there will no doubt be MORE compliance laws, regulations, and rules echoing out of the halls of congress. I would not be worried and thinking too much about SOX, but rather, what else is in the witches brew that could be cooked up on Capital Hill. Think i’m kiding? PCI compliance recently became codified into law in MN with many other states following closely behind.
With SOX staying, you can rest assured that SAS 70 will be hanging around like a little brother. And why not, it’s been a hugely successful internal control auditing mechanism that has shed light on service organizations and how they conduct business.
Compliance is a way of life; as sure as death and taxes. The key is finding a way to meet compliance in a cost-effective and streamlined manner.
The Payment Card Industry Data Security Standard, commonly known as PCI DSS, is a far reaching compliance initiative put forth in a collaborative fashion by the major payment brands (VISA, MasterCard, American Express, Discover, and JCB). These compliance initiatives are overseen and guided by the Payment Card Industry Security Standards Council (PCI SSC).
Thus, if you need to become PCI DSS compliant, there are a number of valuable resources to look at. But first and foremost, you need to understand what Level you fall into for PCI DSS compliance. For merchants, you can be categorized anywhere from a Level 1 to a Level 4. Level 1 audit require an on site PCI DSS assessment, while other Levels you can conduct a PCI DSS Self Assessment. These are general rules, however. Compelling business requirements would require some Level 2, 3, and 4 providers to possibly have an on site audit conducted. Also, there are varying requirements depending on your transaction level between the major payment brands. Find out what your transaction level is, first and foremost.
Additionally, there are also requirements for service providers, thus you will need to identify your transaction level also.