A SOC 1,2,3: From Readiness To Implementation

Transcription

ENTERPRISING PEOPLEAUDITCONSULTINGSOC 1,2,3: From Readiness toImplementationUsing IA ResourcesTAX15301 Dallas Parkway, Suite 960, Addison, TX 75001MAIN 214 545 3965 FAX 214 545 3966 www.bkmsh.com

Kevin M. Rockecharlie, CISA - Director IT AssuranceDIRECT 214 545 3977 EMAIL KROCKECHARLIE@BKMSH.COMBackground:– Kevin Rockecharlie has more than 20 years of experience providingprofessional audit and consulting services to a wide range of industries,including: Energy / oil and gas, financial services, insurance, real estate,retail, technology, telecommunications and settlement trusts. He isresponsible for BKM Sowan Horan’s SOC-1/SSAE16, SOC-2, SOC-3 practice.– Kevin started his career as an ERP developer and now serves both publicand private companies by performing financial, operational and IT audits– In addition, he has extensive experience consulting with clients inautomating internal control testing to achieve SOX 404 compliance.Certifications:Certified Information Systems Auditor (CISA)Certified IDEA Data Analyst (CIDA)Education:MBA, University of Texas at DallasMS Accounting, University of Texas at DallasBBA Management Information Systems, Texas Tech University2

History of SOC (Service Organization Control) ReportIntroduced in June of 2011 as a re-branding andenhancement of the AICPA’s SAS70 standard andreport, Service Organization Control (SOC) reports arebecoming more essential due to the growth ofoutsourcing in the financial, technology and servicesectors. Service organizations that want to remaincompetitive must obtain an internal control attestationwhich is typically a resource intensive process,especially in the first few years of compliance.3

Presentation GoalsOrganizations that understand SSAE16 SOC 1 requirementsand the Trust Services Principles and Criteria for SOC 2allow for greater alignment between the internal andexternal auditors.This session will introduce and discuss the following: Thevarious types of SOC reports, their differences, theirplanning and execution, the identification of systemboundaries and the development of system descriptions,how to align controls with the Trust Services Principles andCriteria, obtaining relevant evidence, the reliance upon thework of the internal audit function and distribution of thereport.** This presentation was primarily developed from AICPA Continuing Professional Education materials forService Organization Control Reporting.4

Comparing SOC ReportsTypeWho needs the reportWhyWhatSOC 1Management of the serviceorganization; user entities; andauditors of the user entities’financial StatementsAudit offinancialStatementsControls relevant touser entities' internalcontrols over financialreportingSOC 2Management of the serviceorganization and other specifiedparties who have sufficientknowledge and understandingOversightdue diligenceControls relevant tosecurity, availability,processing integrity,confidentiality, orprivacySOC 3Any users with need forconfidence in serviceorganization’s controlsMarketing“confidencewithout thedetail”Seal on report & easy toread report on controls5

SOC 1 Report - PurposeReports on controls at a Service Organization Relevant to UserEntities’ Internal Control Over Financial Reporting.SOC 1 reports are examination engagements undertaken by aservice auditor to report on controls at an organization thatprovides services to user entities when those controls are likelyto be relevant to user entities’ internal control over financialreporting.6

SOC 2 Report - PurposeReports on controls at a Service Organization relevant toSecurity, Availability, Processing Integrity, Confidentiality orPrivacy.SOC 2 engagements use the predefined criteria in Trust ServicesPrinciples, Criteria and Illustrations*, as well as therequirements and guidance in AT section 101, AttestEngagements (AICPA, Professional Standards).* See the AICPA guide, Reporting on Controls at a Service Organization, Relevant to Security, Availability,Processing Integrity, Confidentiality, or Privacy (SOC 2).7

SOC 1 Vs. SOC 2 – Explained (Control Risk)The risks and controls that address those risks are likelyto differ in SOC 1 and SOC 2 engagements –Example: Controls over Changes to Application ProgramsSOC 1SOC 2Focus is on risks affecting the financialreporting process at user entitiesCovers the risks of unauthorizedchanges to a much broader range ofapplication programs8

SOC 3 Report - PurposeA SOC 3 report is a general use report that provides only theauditor’s report on whether the system achieved the trustservices criteria (no description of tests and results or opinion onthe description of the system).SOC 3 reports can be issued on one or multiple Trust ServicesPrinciples (security, availability, processing integrity,confidentiality or privacy).9

SOC 2 vs. SOC3SOC 2 Report Components––––Auditor’s OpinionManagement’s AssertionDescription of SystemDescription of Tests and the Results of Tests (Type 2)SOC 3 Report Components–––Auditor’s OpinionManagement’s AssertionDescription of System (Not as detailed as SOC 2)10

Types of Service Auditor ReportsThere are two types of reports for SOC 1 and 2engagements:– TYPE A report on management’s description of the service organization’ssystem and the suitability of the design of the controls to achieve therelated control objectives / criteria included in the description as of aspecified date.– TYPE IIIA report on management’s description of the service organization’ssystem and the suitability of the design and operating effectiveness ofthe controls to achieve the related control objectives / criteria includedin the description throughout a specified period.11

Type II Report - Examination PeriodAfter an organization has conducted operations under thecontrols described in the Type I report for a period of typically sixmonths (or an agreed-upon period of time), a Type IIengagement can be performed. Reasons for a shorter periodmay be described in the report. Controls should be testedthroughout the examination period.To be useful to user auditors, a Type II report usuallycovers a minimum of 6 months. Circumstances for ashorter period may include: The service auditor is engaged close to the date by which the report is tobe issued; The system is in operation for less than 6 months; or Significant changes have been made to the controls, and it is not practicalto wait for 6 months to issue.12

Engagement Planning – Service AuditorThe Service Auditor (CPA) should only accept or continue anengagement if the following conditions are met:1. The service auditor has adequate technical training and proficiency2. The service auditor has adequate knowledge of- the subject matter- the service organization industry and business- systems and technology;3. Reason to believe that the subject matter is capable of evaluationagainst criteria that are appropriate for the intended use;4. Experience evaluating- risks related to the suitability of the design of controls;- the design of manual and IT controls related to the specifiedcontrol objectives (SOC 1) or selected trust services principles (SOC2), performing tests of such controls, and evaluating the results of thetests.13

Engagement Planning – Service Auditor (Cont.)The Service Auditor (CPA) should only accept or continue anengagement if the following conditions are met (Cont):5. Management acknowledges and accepts responsibility to provide theassertion6. The criteria to be used will be suitable and available to the intendedusers of the report7. The scope of the engagement and management’s description of theservice organization’s system will not be so limited that they are unlikely tobe useful to the intended users of the report. If the inclusive method isused, these conditions also apply with respect to the subserviceorganization.14

Engagement Acceptance & ContinuanceManagement’s responsibilities include:–––Description of the service organization’s systemA Written AssertionType of engagement to be performed - Scope- Subservice organizations inclusion / carve out- SOC 1: which control objectives?- SOC 2: which principle(s)?Written representations at the conclusion of the engagementReasonable basis for its assertion15

Assessing MaterialityThe service auditor is required to consider materiality withrespect to the suitability of the design of controls primarily byconsidering qualitative factors, such as whether:Qualitative Factors to ConsiderManagement’s description of the service organization’s system includes the significantaspects of processing of significant transactionsManagement’s description of the service organization’s system omits or distortsrelevant information, orSOC 1: The controls have the ability as designed to provide reasonable assurance thatthe control objectives stated in management’s description of the serviceorganization’s system would be achievedSOC 2: The controls have the ability as designed to provide reasonable assurance thatthe criteria for the applicable trust services principle(s) stated in management’sdescription of the service organization’s system would be achieved16

Planning the Engagement - SamplingIn planning and determining the extent of tests of controls and whethersampling is appropriate, the service auditor should consider thecharacteristics of the population of the controls to be tested, including thenature of the controls, the frequency of their application, and the expecteddeviation rate.The AICPA Audit Guide Audit Sampling addresses designing an audit sampleand projecting and evaluating the results of the audit sample whenperforming audit procedures.Also, for tests of controls using sampling, the service auditor determines thetolerable rate of deviation and uses that rate to determine the number ofitems to be selected for a particular sample.The service auditor’s selection of sample items should be reasonablyexpected to be representative of the population, resulting in a sample that isrepresentative of the population covering the reporting period. Randombased selection of items represents one means of obtaining such samples.17

SOX Readiness AssessmentThe purpose of a readiness assessment is to prepare anorganization for a SOC report engagement. Thereadiness assessment process is similar for both SOC 1& SOC 2 . The eventual, not necessarily the immediategoal, is to successfully complete a Type II engagementand issue a Type II report. A Type II report providesyour customers with the assurance that the internalcontrols processing or protecting their data wereoperating effectively over a period of time.18

Readiness Assessment to Report TimelineReadinessAssessmentRemediation0 to 3 MonthsSOC (1 or 2)Type ITypically 2 to 4 WeeksType IReportSOC 1 or 2Fieldwork3 to 6 MonthsSOC (1 or 2)Type IITypically 2 to 4 WeeksType IReportSOC 1 or 219

Readiness Assessment - Control IdentificationAccomplished through the readiness assessment,which plays a critical part as organizations begin theirSOC engagement process, organizations will documenttheir control objectives and control activities. For a SOC2, an alignment of these controls is required againstrelevant / in scope AICPA Trust Service Principle(s).Control deficiencies will be identified and a gap analysiswill be used to facilitate efforts to remediate issues andprepare for a SOC 1 or 2 Type I report engagement.20

Developing the DescriptionThe extent of the detail in the description may vary dependingon the size and complexity of the service organization and itsmonitoring activities. The description of the serviceorganization’s system is intended to:System Description CharacteristicsEnable user auditors to assess the risks of material misstatementsin the user entities’ financial statementsProvide sufficient information for user auditors to understand howthe service organization’s processing affects user entities’ financialstatements and21

Content of the DescriptionThe description of the service organization’s systemshould include the following:RequirementsThe related accounting records , technology system processes and supportinginformation involved in initiating, authorizing, recording, processing, andreporting transactionsHow the system captures and addresses significant events and conditions otherthan transactionsThe process used to prepare reports and other information for user entities22

Content of the Description - ContinuedService organizations must also include any otheraspects of the service organization’s internal controlcomponents that are relevant to the services provided.These 5 components of internal control include:1. Control Environment2. Risk Assessment Process3. Information and Communication Systems4. Control Activities5. Monitoring Controls23

Control Development & DescriptionIt should also include information about the frequency with which acontrol is performed or the timing of its occurrence, the person orparties responsible for performing the control, the activity beingperformed, and the source of the info to which the control is applied.The following control description is an example that includes all ofthese elements:ExampleThe Cash Reconciliation Group (responsible party)reconciles (activity performed) money movementreflected in the ABC application output report (source ofthe information) to the fund’s custodian bank report(source of the information) monthly (frequency).24

System BoundariesIn a SOC 2 engagement, boundaries of the system mustbe clearly understood, defined, and communicated.Example: The boundaries of a system related toprocessing integrity (system processing is complete,accurate, timely, and authorized) may extend to otheroperations (for example: processes at customer callcenters).25

System Boundaries - PrivacyWhen the privacy principle is addressed in a SOC 2engagement, the system boundaries cover atminimum, all system components, as they relate to thepersonal information life cycle, which consis

15.06.2011 · competitive must obtain an internal control attestation which is typically a resource intensive process, . (CPA) should only accept or continue an engagement if the following conditions are met: 1. The service auditor has adequate technical training and proficiency 2. The service auditor has adequate knowledge of-the subject matter-the service organization industry and business-systems