Soc 1 & 2 Audits Explained

REQUIRED READING FOR
UNDERSTANDING
SOC 1 & 2
Get a SOC 1 Audit Get a SOC 2 Audit
TABLE OF CONTENTS
Five Types of Testing Methods Used SOC Qualified Opinions & What they
During Audit Procedures Mean for Your Organization
When Do You Use the Different Audit Testing Procedures? Four Types of Audit Opinions
What Does the AICPA Say About Using the Available How to Evaluate a Modified Report Opinion Related
Audit Techniques? to Your Service Organization
Types of Controls Understanding an Audit Letter

of Representation (LOR)
Four Types of Internal Controls
When is a Letter of Representation Prepared?
Preventative & Detective Controls
What are the Contents of a Letter of Representation
in Auditing?
Control Objectives & Activities:
What Are They & What’s Appropriate?
What Period Is Covered In A Type II
How to Identify the Right SOC 1 Control Objectives SOC Examination?
for an Organization?
How do Control Objectives Relate to Controls?

SOC Report Types: Type I vs Type II
What is an Integrated Audit? Assessing Similarities Between Type I & Type II SOC Reports
Internal Controls Differences Between Type I & Type II SOC Reports
Planning the Audit When Should You Obtain a Type I vs Type II SOC Report?
Using a SOC report in an Integrated Audit
Audit Sampling in SOC Examinations
Subservice Organizations: Carve-out What are the Different Types of Audit Sampling Methods?
Audit vs. Inclusive Audit Methods
Statistical vs. Non-statistical Sampling
Why be Concerned with Your Subservice Organizations?
How to Determine the Best Method for You? Testing & Audit Exceptions
What are Audit Exceptions? A Definition

SSAE 18 – Attestation Standards: Clarifi- What to Look for When Discussing Audit Exceptions
cation and Recodification in SOC Audit Results
Complementary User Entity Controls, What is a SOC 1 Report? Expert Advice

Considerations, & SOC Reports You Need to Know
Who has Responsibility for Complementary User Entity Who is Required to Have a SOC 1 Report
Control?
SOC 1 Timeline – SAS 70 → SSAE 16 → SSAE 18
Summary of Complementary User Entity Controls
SOC 1 vs. SOC 2 vs. SOC 3 Reports
or CUECs
TABLE OF CONTENTS
SOC 1 (f. SSAE 16) Review Guidance SOC 2 Security Trust Services Criteria
Common Questions on SOC 1 (f. SSAE 16)

Confidentiality vs. Privacy in a SOC 2
Gap or Bridge Letters for SOC 1 Reports What is Included in the Privacy TSC?
What is a Bridge Letter? ‘What is Included in the Confidentiality TSC?
What Does a Bridge Letter Look Like?
Availability Trust Services Criteria
SOC 1 vs. SOC 2 – What is the Difference in a SOC 2 Audit
and How do you Know What you Need? What Additional Testing is Included in the Availability TSC?
What is the Difference Between a SOC 1 and
a SOC 2 Report?
The 10 Generally Accepted
What is the Difference Between a Type I and a Type II Privacy Principles
in a SOC Report?
GAPP Privacy: What are the Generally Accepted
Privacy Principles?
Testing Procedures and Results During a
What Types of Information Require Privacy Protections?
Type II SOC 1 or SOC 2 Engagement
New Criteria for SOC 2 Reporting

What is a SOC 2 Report? Expert Advice on Cyber & Information Incidents
You Need to Know
Old vs. New SOC 2 Incident Reporting Expectations
What is a SOC 2 Report?
Incident Response Considerations:
What Does SOC 2 Stand For?
Who Needs a SOC 2 Report? SOC 1 & 2: 7 Common Mistakes

What is SOC 2 Compliance? The Trust Services Criteria
and How to Avoid Them
(TSC)
Inaccurate Access Controls and Permissions
No Separation of Duties
First time SOC 2 Audit: What to Expect
Who Can Perform a SOC Audit?

Trust Services Criteria
(formerly Principles) for SOC 2 in 2019 What are the Ramifications to the Service Organization
if One of the Above has Happened?
What are the Five Trust Services Criteria
(formerly Principles)? Can a Firm Use the Work of a Specialist to Perform
a SOC 1 or SOC 2 Examination?
Which Criteria do you Include in your SOC 2?
Points of Focus in a SOC 2

Five Types of Testing Methods Used During Audit Procedures
Type II SOC engagements (for both SOC 1 audits and SOC 2 audits) require walkthroughs and testing of
the controls in place at the service organization to be able to opine on the suitability of the design and the
operating effectiveness of controls during the period under review. Each control objective or criteria has a
number of supporting controls that are walked through and tested, and this is accomplished using a variety
of testing methods/procedures.
What are the Different Types of Testing Methods Used During Audit Procedures?
There are five main methods to walkthrough and test each control in place at the service organization.
These methods include (listed in order of complexity from lowest to highest): inquiry, observation,
examination or inspection of evidence, re-performance, and computer assisted audit technique (CAAT).
Inquiry: Simply, the auditor asks appropriate management and staff about the controls in place at the
service organization to determine some relevant information. This method is often used in conjunction
with other, more reliable methods. For example, an auditor may inquire of management if visitors to the }
data center are escorted at all times if the auditor is not able to observe this activity while on site. No control
objective or criteria should ever be supported by controls only tested through inquiry procedures.
Observation: Activities and operations are tested using observation. This method is useful when there is
no documentation of the operation of a control, such as observing that a security camera is in place or
observing that a fire suppression system is installed.
Get a SOC 1 Audit Get a SOC 2 Audit 1

Examination or Inspection of Evidence: This method is used to determine whether or not manual controls are
being performed. For instance, are backups scheduled to run on a regular basis? Are forms being filled out
appropriately? This method often includes reviewing written documentation and records such as employee
manuals, visitor logs, and system databases.
Re-performance: This method is used when the other three above methods combined fail to provide sufficient
assurance that a control is operating effectively or this method can be used to prove and automated controls
it operating effectively. This method of testing (as well as a CAAT) is the strongest type of testing to show
the operating effectiveness of a control. Re-performance requires the auditor to manually execute the control,
such as re-performing a calculation that a system automatically calculates.
CAAT: This method can be used to analyze large volumes of data, or just be able to analyze every transaction
rather than just a sample of all transactions. Software is generally used to perform a CAAT, which can range
from using a spreadsheet to using specialized databases or software designed specifically for data analytics
(e.g. ACL).
When Do You Use the Different Audit Testing Procedures?

Samples of populations are selected for testing based on the type of test being performed (i.e., a test of one
would be completed for an automated control using re-performance, but a sample of the population would
be selected for an inspection control), the population size, and the level of precision we want to achieve in the
testing.
If, during testing, the auditor encounters an error in a test of controls, they will expand the sample size and
conduct further testing, or perform additional tests. Additional types of testing procedures may be required or
useful. If additional errors are found, the auditor will consider whether there is a systematic controls problem
that renders the controls ineffective, or if the errors appear to be isolated instances that do not reflect upon
the overall effectiveness of the control in question.

What Does the AICPA Say About Using the Available Audit Techniques?
The American Institute of Certified Public Accountants (AICPA) provides the guidance for SOC
examinations. Within the SOC guides, the AICPA provides some guidance on what methods of testing are
acceptable.
Statement on Standards for Attestation Engagements (SSAE) No. 18 (Clarification and Recodification) is the
standard governing SOC engagements (AT-C Section 320 for SOC 1 engagements and AT-C Sections 105
and 205 for SOC 2 engagements). Within AT-C Section 320 (Reporting on an Examination of Controls at a
Service Organization Relevant to User Entities’ Internal Control Over Financial Reporting) the following is
specifically stated about testing methods (bold italics were added to emphasize the key points):
“.26 The service auditor should determine through inquiries made in combination with other procedures
whether the service organization’s system has been implemented.” The AICPA is saying that inquiry alone
should not be used. The standard then provides additional information on the types of audit procedures.
“.31 When designing and performing tests of controls, the service auditor should
1. perform other procedures such as inspection, observation, or re-performance in combination

with inquiry to obtain evidence about the following…”
Additionally, specifically within the SOC 1 guide put out by the AICPA, the below paragraph regarding testing
is included (bold italics were added to emphasize the key points):
“4.90 Inquiry alone does not provide sufficient appropriate evidence of the operating effectiveness
of controls. Some tests of controls provide more convincing evidence of the operating effectiveness of
controls than others.” The guide then talks about the combination of testing procedures that provide more
convincing evidence than inquiry alone and provides examples of combinations of tests.

Where are the Types of Testing Used and the Results of Testing Listed in
SOC Reports?
The methods of testing are listed in section IV of SOC reports where the independent service auditor
includes their description of tests of controls and results. Some controls are tested by using only one
method, while other controls may use multiple methods. The methods will be listed out in section IV along
with the results of each of the tests.
Summary
At Linford & Company, we ensure that the audit testing procedures meet the type of controls to confirm
design and operating effectiveness, in addition to complying with guidance set forth by the AICPA.

Types of Controls
In the context of performing a System and Organization Control (SOC) audit, questions arise as to what
are internal controls and what are the types of internal controls. Auditors often take it for granted that
everyone knows and agrees on the definitions of internal controls. We wish it were so. Let’s go over the
most commonly used definitions, at least the ones commonly used by the big four audit firms and the Public
Company Accounting Oversight Board (PCAOB).
What is An Internal Control?

Definition of internal control: An internal control exists when the design or operation of a control allows
management or employees, in the normal course of performing their assigned functions, to prevent or
detect problems in a timely manner.

Four Types of Internal Controls
There are essentially four main types of internal controls that service organizations and their service auditors
should be concerned with, which are namely:
• Manual Controls
• IT Dependent Manual Controls
• Application Controls
• IT General Controls
These four control types are the ones service organizations and their auditors should concern themselves
with since they are pervasive (or at least should be) in the processes that support the systems and services
provided by service organizations to their user organizations (i.e., clients and customers).
Manual Controls
Manual controls are performed by individuals outside of a system.
Examples of manual controls could be a supervisor review and sign-off of a document, or bank
reconciliation, or having an employee sign a privacy policy acknowledgement. Another example of a manual
control could be the manual application (or matching) of cash received in an organization’s lockbox bank
account against a client’s open accounts receivable (A/R) balance. In many organizations, these controls are
done manually, hence the term manual controls.
IT Dependent Manual Controls

Similar to manual controls, IT dependent manual controls require some level of system involvement.
For example, a system-generated report lists users that have not accessed (e.g., logged into a system) a
particular system within the past 90 days. The internal control may require an administrator to review such
report and disable certain users as a result.
The IT dependent portion of this control is the system generated report. The manual portion of this control is
the administrator review of the report and disabling certain users as a result.

Application Controls
There are a great many different forms of application controls. Virtually any configuration setting in a system
that can be used to prevent or detect problems might be classified as a type of application control.
For example, Google G-Suite and Microsoft’s Office 365 can be configured to require two-factor
authentication (e.g., 2FA, MFA) in order for users to login and access system resources and data. Enabling
2FA helps prevent unauthorized users from logging in to the system.
Another example, if the system is configured to lockout a user that enters an incorrect password after three
attempts, it has an application control that detects problems possibly associated with unauthorized access
attempts.
A third example, could be that the system is configured to automatically download and apply security
patches or updates to software (this would have likely helped prevent the Equifax hack (Google search
Equifax).
IT General Controls
This type of control is usually the focal point of most SOC audits. IT general controls are comprised of logical
access, change management, and physical security.
For example, user access administration controls are used so that the right people have the right access
to system resources (i.e., right people & right access). These processes and the controls supporting these
processes are IT general controls.
Another example could be the organization’s change management process tracks and documents that
changes are authorized, tested, approved, and implemented into production. Moreover, all these changes
happen in an environment where there is proper segregation of duties.

Preventative & Detective Controls
In addition to the types of controls named, internal controls are either preventative or detective in nature (note:
sometimes corrective is added; however, it really should be part of detective, as-in detective and corrective).
All other things being equal, preventative controls are generally superior to detective controls. The reason
is this, it is usually easier to correct a situation before a problem occurs than to correct a problem after
detection. Those implementing internal controls into their environment will be well served by implementing
a combination of preventative and detective controls with a greater focus on the former.
Summary
If the controls in the SOC audit report do not seem to fall into one of these four areas, it could be that
a process is being described rather than a control.
Linford & Company service auditors work carefully with the service organizations to make sure that
descriptions of the controls are accurate and support the achievement of the control objectives in a
SOC 1 (f. SSAE 16) audit examination or Trust Services Criteria (TSC) for a SOC 2 audit examination.
It’s also important to note that these definitions and descriptions work equally well for an audit of internal
control in a financial statement audit or internal audits.

Control Objectives & Activities: What Are They & What’s Appropriate?
When we are approached by a prospective client to perform a SOC 1 (f. SSAE 16) audit, we will ask what
control objectives do they want to include in the scope of the examination. In some cases, they have
responded with their own question–What is a control objective? This blog will address that question
as well as how to identify and draft appropriate control objectives for your SOC 1 report.
What is a Control Objective?

There are many definitions for what control objectives are. For example, the PCAOB (Public Company
Accounting Oversight Board) has stated that, for SOX, “a control objective provides a specific target
against which to evaluate the effectiveness of controls.”
Well, the authoritative source for a SOC 1 audit is the American Institute of Certified Public Accountants’
(AICPA) Statement on Standards for Attestation Engagements number 18 (SSAE 18). The AICPA’s control
objective definition provided in SSAE 18 is “the aim or purpose of specified controls at the service
organization. Control objectives address the risks that controls are intended to mitigate.”
As a SOC 1 examination has the added focus on a service organization’s services that may affect a user
entity’s internal control over financial reporting, one could modify the AICPA’s definition slightly and say that
a control objective is the purpose for a set of controls at a service organization to address risks to a user
entity’s internal control over financial reporting.

How to Identify the Right SOC 1 Control Objectives for an Organization?
The control objectives in a SOC 1 report assist a user entity’s auditors in determining how the service
organization’s controls affect the user entity’s financial statement assertions. So, when determining the
control objectives to be included in the description of a report, the service organization’s management
should select control objectives that relate to the types of assertions that are common to a number of user
entities’ financial statements.
Control objectives need to be individually tailored to the activities performed by the service organization.
Additionally, a service organization should strive to have a complete set of control objectives within the
scope of the SOC 1 engagement. Meaning that the control objectives should address all of the major aspects
of the services that may be relevant to user auditors.
Companies providing different services, such as a software as a service (SaaS) and a data center services
providers, would not have the same control objectives in their reports. However, they may have some in
common (i.e., Physical Security). Companies providing the same services will likely have similar control
objectives, but not necessarily the same control objectives.
If you are struggling to identify or are not sure if you have the correct control objectives, you can ask
management of the service organization or a user organization to list the key processing activities provided
to user organizations. This exercise should quickly yield the correct areas for which control objectives should
be formed. Be sure that all control objectives apply to things that the service provider actually performs.

How do Control Objectives Relate to Controls?
So, how do control objectives relate to controls? Control objectives should align with the services offered
to user entities and the related risks to those user entities’ financial statement assertions. Controls are
the activities performed to achieve a control objective to mitigate the risks to the user entities’ financial
statement assertions. Each control activity should specifically relate to a control objective. Each control
objective will typically have several controls related to them.
Example Control Objectives and Controls

So, perhaps the best way to show how control objectives and controls should correlate is by sharing some
control objectives and examples of control activities that have used with them. The following are control
objectives and control activities from actual reports that should help highlight how they should correlate and
align with each other.
Poor Correlation
Control Objective: Controls provide reasonable assurance that logical access to production application
programs and data files is restricted to appropriately authorized personnel and programs.
Control Activity: The acceptable use policy applies to all current and future employees as well as
consultants, temporary staff, and vendors, and applies to new hires requiring password access.
Analysis: The control does not specifically relate to the objective of restricting logical access. While the
policy cited in the control may specify control activities that do restrict logical access, the policy itself does
not control logical access. Some possible controls that could be used to restrict logical access would include:
authorizations within access provisioning process, removing access for terminated employees or contractors,
periodic access reviews, or password settings.

Better Correlation
Control Objective: Controls provide reasonable assurance that changes to the statement application are
authorized, tested, approved, properly implemented, and documented.
Control Activity: Testing is performed to confirm that the change meets the requirements outlined in the
change management documentation.
Analysis: This control is aligned with the control objective. This control is relevant to the tested portion
of the control objective. There are at least four more controls that should also be included to support this
control objective. Those controls should address how changes are authorized, approved, implemented, and
documented.
Summary
In summary, we’ve discussed what a control objective is, how to identify the appropriate control objectives
for a SOC 1 audit, and how control activities should relate to the objectives. Hopefully this has addressed
your questions. If not, we would be happy to discuss them with you. You can contact us here.

What is an Integrated Audit? Assessing Internal Controls
An integrated audit combines a financial statement audit with an audit of internal controls. Since the
Sarbanes-Oxley Act came into effect, management is responsible for establishing, maintaining, and reporting
on an internal control structure, and auditors are required to assess this internal control structure.
Integrated Audit Regulations: Who and When: The Requirements

Public companies must undergo an integrated audit, and only CPAs can perform them.
All public companies, when filing the annual report with the SEC, are required to include an internal control
report. For these companies with a market capitalization in excess of $75 million, the CPA firm auditing
the financial statements is required to express an opinion on management’s internal control report, thus
integrating the financial reporting audit with an internal controls audit.
Although not required, smaller public companies and some private companies may have their auditors use
an integrated audit approach, in case of potential growth or acquisition. Also, auditors may prefer to use an
integrated audit approach, even if not required, because less substantive testing may be required.

The Guidance
The Sarbanes Oxley Act of 2002, section 404, dictates the requirements that management must report
on and assess internal controls and a registered public accounting firm must attest to management’s
assessment. From this requirement, the requirement for an integrated audit was born. SOX 404 Section
404 can be seen on page 45. Also see a related blog post from us: What is the Sarbanes Oxley Act?
Guidance for performing the integrated audit is provided by the PCAOB in Auditing Standard 2201. This
publication provides guidance on planning the audit, incorporating a risk assessment, testing controls,
evaluating weaknesses and deficiencies, and reporting on an opinion.
Management’s Responsibility
The law requires the auditor to attest to management’s assessment of internal controls. See a related blog
post from us: What is an Attestation? In preparation for the integrated audit, management is responsible for
implementing internal controls around financial reporting. Management must document and sign that they
acknowledge this responsibility and include an assessment of the effectiveness of the internal controls they
have established – this is called a management representation letter.
The Highlights: AS 2201

The PCAOB Auditing Standard 2201 does a thorough job of providing guidance and should be the first
resource used for learning about the details of Integrated Audits. In this section, we would like to highlight
some interesting and significant pieces of this guidance.
PCAOB Auditing Standard
Planning the Audit

AS 2201.09 provides a specific list of matters that should be considered when developing procedures for
an integrated audit. In addition to this list, a risk assessment should be performed, focusing on risk that a
material weakness could exist in a particular area of the company’s internal control over financial reporting.
Selection of controls to test, types of evidence to obtain, and testing methods should be designed based on
this level of risk.

Top-Down Approach
The top-down approach begins with understanding the overall risks to controls over financial reporting,
moves to entity-level controls, and then focuses on significant accounts and disclosures which are more
likely to cause the financial statements to be misstated. It is top-down, because it looks at the overall high-
level picture to determine the controls to test.
Entity-Level Controls
The auditor’s evaluation of entity-level controls can influence the amount of testing performed on other
controls. If upper-level management supports a strong, risk-based control environment, control activities
are monitored, risk is continually assessed, and controls are modified based on the assessment, and
management is unable to override control activities, strong entity-level controls are in place, and an auditor
can consider decreasing other controls testing.
Controls Testing: Design vs. Operating Effectiveness

Both the design and operating effectiveness of controls should be tested and evidence should be obtained
to support this testing. First, a walkthrough of the procedures is performed to determine if the control
activities are designed to meet specific control objectives. Then, testing is performed to validate that the
control activities are actually being put into operation in the manner they were designed. The testing of the
controls is where the integrated audit team will spend the majority of their time and efforts.
Reporting
Based on all the evidence obtained from financial substantive audit procedures and control testing, or from
any other sources, the auditor should form an opinion on whether internal controls over financial reporting
were effective. AS 2201.85 – .92 provide specific guidance for report wording and show examples. Although
procedures performed during integrated audits can greatly vary based on company and industry, the
published reports of the auditor are very uniform.
Using a SOC report in an Integrated Audit
SOC Integrated Audit

Controls Performed by a Service Organization
Not all controls are performed internally, as there is an increased use of service organizations to handle
various aspects of each business. If a service organization is used to perform a business process relating to a
significant account or obtains services from another organization that are part of the company’s information
system, the controls performed by this service organization must be evaluated.
Two examples of these cases may be when the entire payroll function is outsourced, or when servers
containing financial data and/or applications processing financial transactions reside in a data center owned
and managed by a third party.
Using a SOC Report

The controls performed by the service organization should be evaluated, but it is not usually feasible to send
auditor to the service organization for a control audit. In this case, System and Organization Controls (SOC)
reports can be used. A SOC report is published by a CPA firm and documents their independent opinion
on the design and/or operating effectiveness of internal controls relevant to the services provided to their
customers. An auditor can obtain the SOC report from the service organization, and review the report for
controls relevant to the services utilized.
The SOC report can provide a level of comfort that the service organization has controls in place around the
significant outsourced services. Although the SOC report is used in forming the audit opinion, the auditor
should not mention or reference the SOC report in the opinion paragraph of the Independent Auditor’s
Report.
PCAOB Auditing Standards 2601 provide additional detailed guidance on the audit impact of an entity’s use
of a service organization: AS 2601. Also see Linford & Co’s past blog post about how SOC reports relate to
Management Assertions: Management’s Assertion and SOC Reports.

Subservice Organizations: Carve-out Audit vs. Inclusive Audit Methods
Service providers often face a common question when determining how best to report on their control
environment to clients who use their services—should we use the carve-out audit or the inclusive audit
method for subservice providers? As service auditors, we’ve been asked this question multiple times by
different service organizations. The short answer is—it depends.
This section will provide you the background and basics surrounding this question and map out the factors
you should consider in determining the best approach for your organization.
What is a Subservice Organization?

The AICPA defines a subservice organization as “a service organization used by another service organization
to perform some of the services provided to user entities that are likely to be relevant to those user entities’
internal control over financial reporting.” You could also think of subservice organizations as the entities that
service organizations outsource some of their operations to.
An example of this is a company that offers its clients a Software as a Service (SaaS) solution that is hosted
by a cloud service organization, which provides physical security, environmental control, and monitoring
services for the SaaS company. In this case, the SaaS company is the service organization and the cloud
services provider is the subservice organization.

Why be Concerned with Your Subservice Organizations?
Information technology has created a more interconnected business world. This has fostered more inter-
reliance between entities around the globe. Accordingly, standards (SSAE 18) have been revised to focus
more on subservice organizations impacting the delivery of critical services.
If you are reading this, chances are you have clients who require your organization to provide them
assurance regarding the control environment surrounding the services provided to them. They are asking
you for a SOC report because their auditors are asking for it. If your clients are SEC registrants, they are
likely asking for a SOC 1 report on your organization’s controls that are relevant to their internal controls over
financial reporting. Otherwise, they are probably asking for a SOC 2 report to gain comfort that you have
adequate controls in place to safeguard their data and systems that interact with your system.
The bottom line is that, as a service provider, it is not enough to just focus on your in-house operations.
You need to have assurance that your subservice providers have controls in place and your organization is
addressing any complementary user entity controls (CUECs) that are expected to be addressed by your
company. See another one of our blogs for more information on CUECs.
What are the Carve-Out Audit and Inclusive Auditing Methods?

The carve-out audit and inclusive audit methods are two ways for a service organization to report the services
performed by subservice organizations within the description of its “system” included in a SOC report.
The carve-out audit method allows a service organization to describe services performed by a subservice
organization within its system description, but excludes the controls and, in the case of SOC 1 reports,
control objectives of the subservice organization. While this approach excludes subservice organization’s
controls, the service organization is required to note within its description of its “system” the controls used
to effectively monitor the subservice organization.
For the inclusive audit method, the service organization’s description of its “system” includes the services
performed by the actual subservice organization (same as the carve-out audit method) as well as the control
objectives and related controls of the subservice organization.

How to Determine the Best Method for You?
Before we jump to a conclusion one way or another, there a few things that you should consider.
The following are considerations that must be evaluated before deciding whether or not to use the
carve-out audit method in a SOC report.
• Are the services performed by the subservice organization relevant to the services offered to your clients?
• If the services are applicable, does the subservice organization receive a SOC report or another form of
certification that will allow you to easily monitor its control environment?
• If the subservice organization can provide a SOC report:
• Did they get a clean opinion in their last report?
• Were there control exceptions noted in the report that would impact the service to your clients?
• Were there CUECs called out in the report?
• If there were CUECs in the report, do you have controls to address them?
• If the subservice organization cannot provide a SOC report, does your organization have another
effective approach to monitor the subservice organization’s control environment (e.g., periodic meetings,
questionnaires, etc.)?
A few key items to consider to determine whether the inclusive audit method should be utilized are:
• Would the subservice organization be willing to have your service auditor test the controls within
their environment?
• Would the subservice organization be willing to provide an assertion letter to be included report—along
with the service organization’s assertion letter?
• How easy is it to coordinate and work with the subservice organization? The two organizations will need to
be able to coordinate schedules for the audit to be performed. Additionally, the two organizations will have
to work together in reviewing and revising the system description within the report.
• Do you want the subservice organization’s results in your report? If the organization historically has
control exceptions, there is a possibility that their performance may impact your clients’ perception of
your organization.

No matter your responses to the earlier questions, your final decision should generally come down to which
method will best meet the needs of your clients.
Summary
While the inclusive audit method is probably the best approach to obtaining the most complete SOC
report, it is often not very practical. There needs to be a solid working relationship between the service
organization’s management and the subservice organization’s management in order for the inclusive method
to be effective, as it requires a great deal of coordination between both entities involved in the SOC audit.
Consequently, in practice, the carve-out audit method is the most commonly used method in SOC reports.

SSAE 18 – Attestation Standards: Clarification and Recodification
The AICPA’s Auditing Standard Board (ASB), recently issued clarifying Statements on Standards for
Attestation Engagements (SSAE). The ASB is issuing the clarified attestation standards as SSAE 18. The old
AT sections in AICPA Professional Standards remains effective through April 2017. The updated statement
by the ASB redrafts all SSAEs and are related to attestation engagements other than financial statement
attestations. The attestation standards establish requirements for performing and reporting on examination,
review, and agreed-upon procedures engagements. Engagements assessing companies’ compliance with
various laws and regulations (e.g., SOC 2, HIPAA, CJIS) are impacted by the revisions.
To facilitate understanding and adoption, the ASB has changed the naming convention of the attestation
standards impacted by the changes made in SSAE 18 to an “AT-C” prefix. The applicability of the updated
AT-C standards depends on the type of service provided and the subject matter of the engagement.

Changes include the following clarity drafting conditions:
• Establishing objectives for each AT-C section.
• Including a definitions section, where relevant, in each AT-C section.
• Separating requirements from application and other explanatory material.
• Numbering application and other explanatory material paragraphs using an A- prefix and presenting them
in a separate section that follows the requirements section.
• Using formatting techniques, such as bulleted lists, to enhance readability.
• Including, when appropriate, special considerations relevant to audits of smaller, less complex entities
within the text of the AT-C section.
• Including, when appropriate, special considerations relevant to examination, review or agreed-upon
procedures engagements for governmental entities within the text of the AT-C section.
One of the main focuses of SSAE 18 is to allow the practitioner the ability to create a framework for
engagements that meet client needs. The clarifications now allow the practitioner to report on almost any
subject matter provided:
• The party responsible for the subject matter is someone other than the practitioner and takes responsibility
for the subject matter.
• The subject matter is appropriate.
• The criteria to be used in evaluating the subject matter are suitable and available.
• The practitioner expects to be able to obtain evidence needed to arrive at the practitioner’s opinion,
conclusion, or findings through access to information and unrestricted access to people who can provide
such evidence.
• The practitioner’s opinion, conclusion, or findings are to be contained in a written practitioner’s report.
What’s new? – In addition to the restructuring of the SSAEs, the following are some of the changes
introduced by SSAE 18:
• Separate discussion of review engagements – SSAE 18 separates the detailed procedural and reporting
requirements for review engagements from their counterparts for examination requirements.
• Required representation letters – SSAE 18 requires the practitioner to obtain a representation letter for
all engagements. This is different than AT section 101 which discusses representation letters, but does not
require them.
• Risk assessment for examination engagements – SSAE 18 requires practitioners to obtain a more in-depth
understanding of the development of the subject matter than was required in the past in order to better
identify the risks of material misstatement.=
• Incorporation of detailed requirements – SSAE 18 incorporates a number of detailed requirements (e.g.,
representation letters) that are similar to those contained in Statements on Auditing Standards (SASs).
• Scope limitation imposed by the engaging party or the responsible party – SSAE 18 indicates that based on
the practitioner’s assessment of the effect of the scope limitation, the practitioner should express a
qualified opinion, disclaim an opinion, or withdraw from the engagement. The current AT section 101
standard requires that a practitioner should disclaim an opinion or withdraw from the engagement altogether.

The concept of user control considerations within SOC reports has been around since SOC reports were
referred to as SAS 70s, although the AICPA’s term used to describe user control considerations has changed
over time. These controls are now known as complementary user entity controls (CUEC). You may also hear
these controls referred to as client control considerations or user control considerations.
What are Complementary User Entity Controls?

CUECs are controls that reside at the user entity level of a service organization. User entities are
organizations that utilize the services of a service organization.
When using a service organization, there are certain controls that remain the responsibility of a user
entity. For example, consider a user entity that uses a common file sharing program such as Dropbox.
When employees terminate from the user entity, the user entity must remove the former employees’ access
to the file sharing program. The file sharing program (service organization) has no way to know when a
user entity’s employee access should be removed. As a result, the user entity must remove the former
employees access to the file sharing program upon termination. This is an example of a common CUEC.
More Examples of CUECs:

MSP Environment Changes – A user entity uses uses a managed IT service provider (service organization) to
make changes to its environment, however, no changes are made to the service organization without explicit
approval from the user entity. In this example, the service organization’s report would say that user entities
must approve all changes prior to implementation.

• Encrypted Financial Data – A service organization works with banking institutions that send large amounts
of data periodically to the service organization. A CUEC within the service organization’s report may say
that user entities must send data in an encrypted manner using industry standard encryption or request
that the service organization provide a secure transmission method.
• Security Monitoring – User entities must monitor and update their own antivirus definition updates and
security patches unless the service is included within a contracted Statement of Work with the
service organization.
• Physical Access – It is the responsibility of user entities to notify the service organization in the event that
physical access needs to be added, modified, or revoked for a user entity’s employees.
• Contingency Plan – The service organization’s contingency plan is applicable to its operations only. User
entities are not covered by it and should develop their own contingency plan.
When reviewing SOC reports, user entities should review all CUECs where the user entity must perform certain
controls. These controls are usually delineated SOC reports within their own report sub-section and/or next to
the control objectives they relate. CUECs together with the control activities at the service organization work
in conjunction to achieve the related control objective (SOC 1) or Trust Service Criteria (SOC 2).
Most SOC audit reports have CUECs since they are integral to the design and operating effectiveness of the
control environment. The CUECs are usually tested by the user auditor in conjunction with the performance
of the financial statement audit of the user organization. If a SOC audit report does not have any CUECs, this
may be an indication of an incomplete report and therefore lead to inadequate audits at user organizations.
If in doubt, talk to the service auditor. In most cases, they should be more than willing to answer questions
on CUECs.
Complementary vs. Compensating Controls

What is the difference between complementary controls versus compensating controls?
Complementary Controls: These are controls that work together at an organization to achieve the same
control objective. Using an example from above, if a service organization is not notified to make a change to
a user entity’s access list, they will not remove the access for the user entity’s employee when they terminate
employment. The result is that an individual who is no longer authorized to have access to the user entity’s
environment at the service organization may retain access.

Compensating Controls: Compensating controls are usually put in place when it is too difficult to implement
a primary control for a particular requirement. For example, many service organizations know that not all of
the user entities that use them notify them consistently when user entity employees terminate employment.
To compensate for not being notified properly to remove terminated employee access, a service
organization may implement an account lockout feature so that when a user does not login for an extended
period of time (e.g., 60 days), their account is locked. This would compensate for the user entity neglecting
to notify the service organization to remove access. Of course, the terminated employee could still have
accessed the service organization’s environment for up to 59 days, however, this type of control still reduces
risk related to logical access at the service organization.
Who has Responsibility for Complementary User Entity Control?

User entities are responsible for the performance of CUECs. If user entities do not consistently perform
CUECs, it is possible that the control environment at user entities may have failures even if the controls at
a user entity’s service organizations are designed and operate effectively. It is important for user entities to
review any applicable CUECs as part of the SOC report review process for any service organizations in use. If
there are any CUECs, the user entity should ensure that they are performing the CUECs consistently over the
period a given SOC report is relied on.
What are my Organization’s Complementary User Entity Controls?

Your organization’s CUECs can be found within the SOC reports for any service organizations that are
used by your organization. CUECs are included within SOC reports in the applicable control objective or
process area. Using the example above where a user entity must remove access for any former employees to
Dropbox, Dropbox’s SOC report should have a CUEC for its user entities within the logical access section of
the report.

Summary of Complementary User Entity Controls or CUECs
A SOC report for any service organization must be evaluated along with any applicable CUECs at the user
entity. If CUECs do not operate effectively at a user entity, control failures could still occur related to the use
of a particular service organization. Review your SOC reports for any CUECs and ensure that your user entity
performs these controls consistently and has a process to review SOC reports annually and ensure that any
CUECs are identified and tracked.
See our past Linford & Company blog posts related to identifying the correct SOC report for your service
organization as well as the impact of any findings within your SOC report.

SOC Qualified Opinions & What they Mean for Your Organization
Qualified opinions mean that either the internal controls were not designed (Type I or II) or operating (Type
II only) effectively for one or more control objectives included within a SOC 1 report or Trust Services Criteria
included within a SOC 2 report.
In a SOC report, management asserts that certain controls are in place. If the auditor performs test
procedures that contradict management’s assertion, they may issue a qualified report opinion. See our
recent blog post on assertions.
Qualified opinions (also known as “dirty opinions” in audit jargon) are actually quite common. Many service
organizations that have received a qualified opinion received it in the first year of the examination, but
it’s also common for control failures to occur when controls have operated successfully in the past. One
common reason for report qualification is due to employee turnover if a control performed by a former
employee is no longer performed consistently by another employee.
A qualified opinion means that the user organization and the user auditor cannot place reliance on the
controls supporting a particular area at the service organization. Note that a single qualification does not
mean that reliance may not be placed on other areas of the report with no qualifications.
Example: A service organization fails to disable access for a former employee. The employee continues to
access the service organization’s systems following termination as evidenced by logs. In this case, there
would be a logical access qualification within the report which would be reflected by the CPA firm’s opinion
in the report.

Service auditors and organizations alike should not back down from a situation where the report needs to be
qualified. Management should recognize mistakes or other errors in processing and auditors should not be
afraid to call out a problem. Both parties should place public interests first and foremost, and sometimes this
means “calling a spade a spade.”
How Bad is a Qualified Report Opinion?

How bad is a qualified report? This question comes up almost every time a qualified report is issued to a
service organization. The person asking this question is usually comparing a qualified service auditor’s report
(e.g., SOC 1) to a going concern opinion on a financial statement audit. Both are bad. But how bad?
A going concern opinion often means the organization is in financial peril and may meet its demise very
soon. However, a qualified opinion on a service auditor’s report is more akin to a material internal control
weakness disclosure for SEC registrants who have to issue such disclosures for Sarbanes-Oxley Act
purposes.
A qualified opinion in a service auditor’s report is similar to a significant deficiency or material weakness in
internal control disclosure. All should be avoided by management. Though the going concern opinion is the
worst of the opinions just described.
Qualified Report Opinion vs. Going Concern

What is a going concern? A going concern is the ongoing assumption that an organization or entity will
continue to operate for a period of time sufficient to meet its obligations. A SOC report qualification is
related to one or more areas covered in the scope of the report and does not relate to the ongoing operation
of a service organization. It is possible for an organization with a going concern to have no issues in its SOC
report, but still have an issue related to going concern. It is also possible that an organization has a qualified
report, but no issues relating to going concern.

Four Types of Audit Opinions
Below are the four types of audit opinions and their definitions:
1. Unmodified – This is a clean report opinion with no modifications.

2. Qualified – Qualified opinions are expressed when auditors conclude that they cannot express unqualified
opinions, and the effects of disagreements with the organization’s management or limitation of scope is
not so pervasive and material as to require adverse opinions or disclaimers of opinions. The example
above related to logical access would result in a report qualification and unless there were pervasive issues
across other areas of the report, there would not be an adverse opinion.
3. Disclaimer – A disclaimer opinion is provided when auditors can’t express an opinion. This typically
occurs when an organization limits the auditors. For example, if the company does not provide the
auditors with adequate information to give an opinion, the CPA firm may disclaim their opinion. Other
instances when auditors may not be able to render an opinion include: when books of accounts are
not appropriately maintained and when the auditors are unable to perform procedures they believe are
necessary.
4. Adverse – An adverse opinion is the most severe opinion that a CPA firm can provide. Misleading or
incomplete financial statements may lead auditors to give an adverse opinion. An adverse opinion in
the context of a SOC report often means that the report users cannot place any reliance on the service
organization’s system.

How to Evaluate a Modified Report Opinion Related to Your
Service Organization
What if you request your service organization’s control report and it contains a qualified opinion? Should you
be concerned? The answer is… it depends. The qualified area of the report must be considered in relation to
the services being utilized by the user organization.
For example, if there is a qualification related to physical access which is an aspect of a service
organization’s service that is not relevant to the user organization, then it is possible that the qualification in
that area is not relevant to the report user. If an organization is considering outsourcing the physical security
of its servers to another service organization and the service organization has a qualified physical access
control objective, the service organization may consider using a different subservice organization.
Summary
To summarize, SOC report qualifications are fairly common. They relate to an area of the report that an
auditor finds exceptions related to. If the exceptions are severe enough in a particular area the auditor may
provide a qualified opinion related to the area with issues.
Qualified opinions should be considered in context to the services being received by a user organization. If
the qualification potentially impacts the services provided to a user organization, the user organization must
consider whether the issues are severe enough to warrant using a different service organization.

Understanding an Audit Letter of Representation (LOR)
This article addresses the what, when, why, and who’s related to letters of representation for audits,
specifically SOC audits.
What is a Letter of Representation?

A letter of representation (aka representation letter, rep. letter, LOR) in audit services is a form letter from
the American Institute of Certified Public Accountants typically prepared by the external auditors on behalf
of a company’s management that is signed by a member of executive leadership. By signing the letter of
representation, the executive attests to the external auditor that all of the information submitted is accurate,
and that all material information has been disclosed to the auditors. For a financial audit, that material would
be the financial statements and internal controls over financial reports. In the context of a SOC 1 or SOC 2
examination, company representation letters allow the management of the company to not only confirm
that all material information has been disclosed to the service auditors, but also to take responsibility for the
presentation and accuracy of the assertion and description in the report and to confirm that the controls
were designed and operating effectively during the period of the assessment.
As you can imagine, a letter of representation is an important piece of evidence in any audit. Management’s
representations and attestations in the letter provide some assurance that the information provided during
the examination is reliable to use in audit procedures and to base its opinion. Management’s attestation in
the representation letters also shifts blame to management in the case that a control failure is missed during
an audit or inaccuracies because information was not made available or disclosed to the service auditor.

When is a Letter of Representation Prepared?
As it is a form letter, a letter of representation may be prepared at any point during a SOC 1 or SOC 2
examination. However, paragraph .54 of AT-C section 205 (SSAE 18) specifies that a representation letter must
be dated as of the date of the service auditor’s report. The letter may be signed any time from the date of
the report and the report is issued. However, because it is an important piece of evidence supporting an audit
opinion, the letter of representation should be signed before the report is issued (AICPA’s SOC 1 Guide 4.189).
Why is the Letter of Representation Important?

As noted earlier, the simple answer is that the letter of representation is required by the American Institute
of Certified Public Accountants, the governing body for attestation services. If management refuses to
provide the requested representations, the service auditor would consider it “a limitation on the scope of
the examination sufficient to preclude an unmodified opinion and may be sufficient to cause the practitioner
to withdraw from the engagement” (Paragraph .A64 of AT-C section 205). Similar actions would be taken
should the service auditor conclude that there is sufficient doubt about the competence, integrity, ethical
values, or diligence of those providing the written representations; or the service auditor concludes that the
written representations are otherwise not reliable and is unable to resolve the concerns through additional
procedures. From a practical standpoint, because management’s written representations are an important
consideration when forming the service auditor’s opinion, the service auditor would not ordinarily be able to
issue the report until the service auditor had received the representation letter.
Who is Responsible for the Letter of Representation?

The AICPA’s guidance requires, when the engagement covers a modified or extended period, that the
auditor obtain management’s written representation in the form of a representation letter addressed to the
auditor. The AICPA requires that the service auditor request the written representations from management.

What are the Contents of a Letter of Representation in Auditing?
Paragraph .38 of AT-C section 320 (SSAE 18) states that “the service auditor to request from management
written representations required by paragraph .50 of AT-C section 205 as well as those required by
paragraph .36 of AT-C section 320.” The auditor and management may add additional representations to the
letter. The written representations required by paragraph .50 of AT-C section 205 are identified in items a-i
and the written representations required by paragraph .36 of AT-C section 320 in items j-k.
The following summarizes the minimal representations to be included in the letter:
A. Include the management’s assertion about the description, controls, control objectives (SOC 1), and trust
services criteria (SOC 2) based on the criteria.
B. A statement that all relevant matters are reflected in the description or evaluation of the related controls
or assertion.
C. A statement that all known matters contradicting the control objectives, trust services criteria, or
assertion and any communications from regulatory agencies or others affecting the control objectives, trust
services criteria, or assertion have been disclosed to the practitioner, including any communications between
the end of the period addressed and the written assertion and the date of the service auditor’s report.
D. Acknowledge responsibility for:

1. the description in the report and the assertion:
2. selecting the applicable criteria; and
3. determining that the applicable criteria is appropriate.
E. A statement that any events after to the period (or point in time) related to the description, control
objectives, or trust services criteria being reported on, which would have a material effect on the control
objectives, trust services criteria, or assertion, have been disclosed to the auditor.

F. A statement that the individual signing and the company have provided the service auditor with all
relevant information and access.
G. When applicable, a statement that the individual signing believes the effects of uncorrected
misstatements are immaterial, when considered individually and in aggregate, to the control objectives or
trust services criteria.
H. When applicable, a statement that significant assumptions used to make any material estimates are
reasonable.
I. A statement that the individual signing and the company have disclosed the following to the service auditor:
1. Any and all deficiencies in internal control relevant to the engagement of which the responsible
party is aware;
2. Knowledge of any actual, suspected, or alleged fraud or violation of laws or regulations affecting
the control objectives or trust services criteria; and
3. Other matters as the service auditor deems appropriate.
J. A statement that any instances of noncompliance with laws and regulations or uncorrected misstatements
attributable to the service organization that may affect one or more user entities have been disclosed to the
service auditor.
K. A statement that any knowledge of actual, suspected, or alleged fraud by the management or employees
of the service organization that could adversely affect the fairness of the presentation of management’s
description of the service organization’s system or the completeness or achievement of the control
objectives stated in the description have been disclosed to the service auditor.
Summary
An audit letter of representation is a form letter prepared by a company’s service auditor and signed by a
member of senior management. In the letter, management attests to the accuracy and completeness of the
information provided to the service auditors for their analysis. The letter must be dated as of the date of the
report and signed on or after that date. The service auditor must obtain a signed representation letter that
includes, at a minimum, the required representations specified by the AICPA in order to opine an audit.

What Period Is Covered In A Type II SOC Examination?
A Type II SOC 1 (f. SSAE 16) or SOC 2 report (versus a Type I) is the most useful for a service organization
to provide to a client. Most reports cover a 12 month period, but can be as short as six months. So how does
a service organization decide what period under review is right for them? The best answer would be to
evaluate what period would overlap the most with the majority of their client’s financial year. Because the
reader of the report is generally the user (client) auditor, the report is most useful to clients when it overlaps
at least six months with the client’s financial year under review.
Below are some excerpts from the AICPA’s SOC 1 guide addressing the period under review.
2.14 The user auditor evaluates whether the period covered by a given Type II report is appropriate for the
user auditor’s purposes. To provide evidence in support of the user auditor’s risk assessment, the period
covered by the Type II report would need to overlap (typically at least six months) the user entity’s audit period.
2.16 The service organization may consider the following examples when determining an appropriate test
period for a Type II report.
• Example 1. The majority of user entities have calendar year ends. The service organization may want
to provide a Type II report for the period November 1, 20X0, to October 31, 20X1, to maximize the
usefulness of the report to user entities and their auditors.
• Example 2. User entities have year ends that span all months of the year. The service organization
determines that issuing a report each quarter (or more often than annually) with tests of operating
effectiveness that cover twelve months is most likely to maximize the usefulness of the report to user
entities and their auditors.

Based on the above guidance, and our years of experience performing these examinations, Linford &
Company recommends that the service organization consider the financial review period of their clients,
or if needed, inquire of clients if there is a preference of the period covered by the SOC report. Completing
the SOC report annually, with a continuance 12 month period being covered, allows a service organization
to provide clients with a report that opines on the service organization’s controls year over year without a
break in the period being covered.
For the period of time that does not overlap with a service organization’s client’s financial year, a bridge
letter may be issued by the service organization saying that their controls did not change during that period,
or if they did change an explanation of the changes that occurred to the controls in place.

SOC Report Types: Type I vs Type II
If you are being asked to obtain a Service Organization Control (SOC) report by your existing user entity or
a potential user entity, you may question whether you should obtain a Type I or a Type II report.
If you are a service provider that is considering your first SOC audit to satisfy an existing or potential user
entity request, it may benefit you to understand the difference between SOC report types, specifically a
Type I audit report and a Type II audit report, and when you should choose one over the other.
Similarities Between Type I & Type II SOC Reports

There are several similarities between the reports. Both reports provide the user with an overview of the
service organization’s system in place utilized by the user entities. Control objectives are documented that,
in aggregate, form the basis for how the service organization reliably provides the service to achieve the
service commitments and system requirements utilized by the user entities.

Individual internal controls are linked to these control objectives that provide the process the service
organization undergoes to ensure the achievement of those stated control objectives. There are typically
multiple controls linked to a control objective. A description is also included of the complementary
user entity controls required to be in place at the user entity for the entire system of controls to work in
aggregate to achieve the stated control objectives.
Additionally, a management’s assertion from the service organization is provided that addresses the description
of the service organization’s system and whether the controls are suitably designed to provide reasonable
assurance over the service commitments and system requirements to meet the stated control objectives.
Differences Between Type I & Type II SOC Reports

The main difference between the two types of reports is within the coverage and depth of the audit
procedures performed.
Type I SOC Reports

A Type I audit report is as of a point in time (e.g., September 30). It only covers the design effectiveness of
the internal controls that help you to meet your control objectives over the outsourced services that you are
providing to your user entities and for which they are relying upon from your service organization. The Type I
audit report attests to the suitability of the internal controls linked to the control objectives and validates the
sufficiency of the controls in aggregate to meet the achievement of the control objective described. A readiness
assessment can be performed even before the Type I SOC Report for your service organization to understand
their existing controls and recommendations that should be implemented prior to the full Type I SOC assessment.
Type II SOC Reports

A Type II audit report covers a period of time typically twelve months (e.g., October 1, 2018 – September
30, 2019). This type of audit report covers the design of the internal controls as well as the operating
effectiveness of the internal controls over time that help you to meet your control objectives over the
outsourced services provided to your user entities. A Type II SOC engagement provides reasonable
assurance that the controls operated effectively to meet the service organization’s control objectives over
the service commitments and system requirements during the period of time under review.

A Type II SOC engagement effectively addresses the same subject matter as a Type I SOC engagement;
however, a Type II SOC report goes further in that it contains an opinion on the operating effectiveness
of controls over the time they were operating and provides a detailed description of the tests of controls
performed by the service auditor as well as the results of those tests. The results of those tests will indicate
whether the control performed without exception or else the exception noted will be documented in the
service auditor’s report.
When Should You Obtain a Type I vs Type II SOC Report?

If this is your first foray into obtaining a SOC report, whether a SOC 1 or SOC 2 report, these are the two
attestation options available, either a Type I or a Type II. It is generally best to obtain a Type I audit report
initially before moving on to the more comprehensive Type II audit report. This approach allows the service
organization to understand the audit process and the audit requirements in order to set expectations of
what will be required to undergo a Type II audit report.
A Type I audit report helps the service organization to implement the discipline necessary to successfully
complete an unqualified Type II audit report. Generally speaking, at least six months must elapse in order to
have a Type II audit report because this type of audit report covers a period of time. A Type II audit report
generally covers a period between six months and one year.
When existing or potential user entities are looking for assurance that a service provider has a SOC report,
obtaining the Type I audit report initially is a great way to show commitment while the organization is
setting internal expectations and preparing for the more comprehensive Type II audit report.
Another difference between a Type I and a Type II audit report is that for the SOC report to be relied upon
by user auditors, the SOC report should cover a minimum reporting period of six months. This is only
achieved through a Type II audit report because it covers a period of time. A Type II audit report provides
the user auditors with a higher level of assurance for them to rely on.

Summary
Type I SOC Report Summary

A Type I SOC presents the auditors’ opinion regarding the accuracy and completeness of management’s
description of the system or service as well as the suitability of the design of controls as of a specific date
and does not test whether the controls are operating effectively over time.
Type II SOC Report Summary

A Type II SOC includes the Type 1 criteria AND audits the operating effectiveness of the controls throughout
a disclosed period of time, generally between six months and one year. It also describes the tests performed
of the controls and the test results.

Audit Sampling in SOC Examinations
In completing SOC 1 and SOC 2 examinations (and most other types of audits), there is testing involved to
determine the operating effectiveness of controls. There are different types of tests that can be applied to
testing controls (for more information on the five types of tests refer to our article, Five Types of Testing
Methods Used During Audit Procedures), and to complete a majority of these tests there is a sampling of
populations that are required. In this section, we will cover what audit sampling is and provide guidance on
how to apply audit sampling to get to a confident conclusion on the operating effectiveness of controls.
According to the AICPA (in SAS No. 122 AU-C Section 530), audit sampling is defined as “The selection and
evaluation of less than 100 percent of the population of audit relevance such that the auditor expects the
items selected (the sample) to be representative of the population and, thus, likely to provide a reasonable
basis for conclusions about the population.” The entire AICPA audit sampling guide can be referenced here.
Why do Auditors Use Sampling? What is the Purpose?

The definition from the AICPA is a little wordy, but to summarize, as auditors, the purpose of audit sampling
is to allow us to do the right amount of testing to confidently determine the operating effectiveness of
controls. This does not mean we can always test 100 percent, or even have the capacity to. Therefore,
sampling comes into play in testing. But what is the right amount and how do you figure that out?
As auditors we need to consider three primary areas when performing audit sampling: 1) sample method, 2)
the sample size, and 3) tolerable rate of deviation.

What are the Different Types of Audit Sampling Methods?
There are four main types of audit sampling methods that are used when completing tests of controls in
SOC 1 and SOC 2 examinations. The type of population, how it was generated, and the size of the population
can have an impact on the type of audit sampling methodology that is chosen for testing. The four main
types include:
• Simple Random Sampling – Every unit has the same probability of being selected. This type of sampling
can easily be accomplished by assigning a number to each item in the population and then using a random
number generator to randomly select numbers in the range of the population (there are online tools for this,
apps, and even Excel formulas can be used to generate random numbers).
• Systematic Sampling – This method selects samples using internals which are a result of dividing the
population of units by the sample size. For example, if there are 250 items in the population and 25 will be
selected for testing, 250 is divided by 25 to come up with 10, therefore every 10th item in the population will
be selected for testing.
• Haphazard Sampling – Similar to simple random sampling; however, random number generators or tools
are not used, and selections are just made from the population without any bias.
• Block Sampling – Represents contiguous population items, for example, the five most recent transactions in
a population or the five most recent events can be selected for testing. Block sampling would include testing
100 percent of a population.
• Every SOC examination should follow one or more of these sampling methods for testing of the
population. A walkthrough or inquiry only would not be sufficient to test all controls.

Statistical vs. Non-statistical Sampling
Statistical sampling requires that samples be selected at random, generally using a tool to generate
random numbers. The simple random sampling method above would be considered statistical sampling.
Non-statistical sampling allows an auditor to use professional judgment when selecting samples.
Non-statistical methods make a lot of sense when a population is very small, rather than spending the time
setting up a statistical sample. While non-statistical sampling allows for auditor judgment, an auditor should
always be careful not to include too much bias in selecting samples.
What is the Appropriate Sample Size?

There are a number of factors that need to be considered when determining the sample size.
1. The size of the population being tested.
2. The risk of the control. All the controls that the auditor has selected to test are significant controls, but
there is a spectrum that exists regarding the significance of each control. It is important to consider the
impact (qualitatively and quantitatively) if a control is not operating effectively.
3. How many deviations/failures would be acceptable in testing the specific control.
The tables below (Table 1 and Table 2) are what we use as guidelines when selecting our sample sizes in our
SOC 1 and SOC 2 examinations. These tables align with the guidance set forth in the audit sampling guide
from the AICPA.

Table 1
Sampling Table Based on Population Size 90% Confidence Level
Control Risk Assessment & Population Size
Number of Low Moderate
Deviations (5-7% Tolerable Rate (8-10% Tolerable Rate)
<100 100-=200 >200 <100 100-200 >200
0 30 35 40 20 22 25
1 45 50 60 30 35 40
2 65 75 90 45 50 60
Table 1 is used for larger sample sizes (250 or greater in the population) and shows recommended sample
sizes to get to a minimum 90% confidence level. The table includes the sample sizes for up to two deviations
and takes into consideration the risk of the control.
Table 2
Sampling Table for Infrequently Operating Controls
Control Frequency and Population Size Sample Sie
Annually 1
Quarterly 2
Monthy 2-4
Weekly 5-9
Transactional See Table 1 and at least 5
Continuous 1
Daily See Table 1
Table 2 gives further guidance sampling on less frequent operating controls and on smaller populations
(transactional).
Audit Sampling Examples

Using the tables above a few examples would include:
Example 1: A population of all employees is provided and consists of 389 people and you want to test that
all employees are attending security awareness training. According to the table, expecting no deviations, the
initial sample would be 25 and simple random or haphazard sampling would likely be applied. If it is found
that one of the 25 selected did not attend training, the sample would be expanded to 40 people. If another
deviation is found, the sample would be expanded to 60. If another deviation is found, sampling would stop
and it would be determined that the control is not operating effectively.

Example 2: The controls being tested states a monthly reconciliation is completed and you want to test that
it was indeed completed monthly and reviewed by a manager. Using Table 2 above, you would select three
months for testing. Using haphazard sampling you would pick three months from the year and test those
months. Because the population is smaller, any deviations would be a failure of the operating effectiveness
of the control.
Summary
The guidance from the AICPA is pretty extensive around audit sampling. SOC auditors should review
their sampling methods to make sure they are aligned with the AICPA guidance when performing their
examinations.

Testing & Audit Exceptions
If you are reading this article, chances are that your auditor has told you that you have an audit exception
or, even worse, multiple “audit exceptions.” Hearing that phrase strikes fear and panic into the hearts of
many. While some of those reactions may be justified, we have found that many suffer more than necessary
because they are not familiar with the vocabulary used in these discussions, do not really know what an
exception is, or do not understand the audit process. This section will briefly summarize the purpose and
process of an audit, define what audit exceptions are, and clarify what to look for when discussing the results
of an audit.
Realizing that there are many types of audits, we will use SOC 1 or SOC 2 audits as the basis for this
discussion. While other audits may be assessing different things and may have different types of exceptions,
the basic principles and process described here can be applied across broad range of audits.
What is the purpose of SOC Audit?

1. System and Organization Control (SOC) audits are designed to provide an independent and objective
assessment of a service organization to users of the services or system that the service organization
provides. There are three things an auditor of the service organization is trying to determine:
2. Is the service organization’s description of its system and services accurate or presented fairly?
Are the controls described by the service organization suitably designed to achieve the related control
objectives or criteria?

3. Did the controls described by the service organization operate effectively during the period covered by
the assessment to achieve the related control objectives or criteria?
An auditor must gather sufficient evidence to evaluate and answer these questions with reasonable
assurance to support the unqualified or qualified opinion to be written in the audit report. The process of
gathering evidence is called auditing and will include a number of different activities.
For example, auditors may gather information by inquiring of appropriate personnel (management,
supervisors, and staff); inspect documents and records; observe activities and operations being performed;
and tests of controls. All of these activities used to gather and evaluate evidence are often referred to as
audit procedures or audit tests.
What are Audit Exceptions? A Definition

Audit exceptions are simply deviations from the expected result from testing one or more control activities.
Each control in a service organization’s description must be tested by an auditor to validate that the
description is accurate and that controls are suitably designed and operating effectively to achieve the
related control objectives or criteria. An auditor may use one or more tests to evaluate each control. As with
any test, there are expected outcomes or responses.
Consider the following example that you might see in a SOC audit:
• Control Objective: Controls provide reasonable assurance that statement processing is appropriately
scheduled and that deviations in processing are identified and resolved.
• Control Activity: Statement batch totals are used in order to identify and resolve deviations in processing.
• Testing Performed: Inspected a sample of batches used to process statements and noted that batch
control totals were used to help maintain the integrity of the statements processed.
Using this example, if an auditor performed this test and found that one or more of the batches selected for
testing did not use batch control totals, as expected and indicated in the service organization’s description,
the auditor would note a deviation. These deviations go by many names: audit exceptions, test exceptions,
control exceptions, deficiencies, findings, misstatements, and so on.

The Cause & Nature Audit Exceptions
An auditor must investigate the nature and cause of any audit exceptions identified to determine whether:
• The identified exceptions are within the expected rate of deviation and are acceptable.
• Additional testing of the control or of other controls is necessary to reach a conclusion about whether the
controls related to the control objectives or criteria stated in management’s description of their system or
services operated effectively throughout the specified period.
• The testing that has been performed provides appropriate basis for concluding that the control did not
operate effectively throughout the specified period.
What to Look for When Discussing Audit Exceptions in SOC Audit Results
Auditors have their own vernacular that may cause confusion and worries. We like to compare audits to
taking a trip to the doctor’s office:
Imagine after suffering with an illness for a few days, you finally go in and see a doctor. The doctor visits with
you, inspects you by doing a few checks personally, and may even order a few tests (i.e., blood work) before
coming back to share the prognosis at the conclusion of your visit. The doctor sits down in front of you and
stoically shares that you are suffering from nasopharyngitis or acute coryza. You don’t necessarily know what
that is, but it sounds horrible—much more serious than you had thought. In the moments after hearing the
initial prognosis, your heart rate starts to pick up, you begin to sweat (if you weren’t already), and your mind
begins to race. Seeing your reaction, the doctor quickly clarifies, “That means you’ve got a cold. You need to
get some rest, stay hydrated, and take some pain medication.”
That’s kind of what it’s like when you are visiting with your auditors after an audit. You know there were
a few exceptions, but you’re not sure what it means or just how bad is. Well, not all audit exceptions are
created equal.

Types of Audit Exceptions
Audit exceptions can be intentional or unintentional, qualitative or quantitative, and include omissions.
Auditors are required to make sure a service organization’s description is accurate and to include all design
and operating deficiencies in the report—they no longer have discretion in determining whether or not to
include exceptions.
There are three basic types of exceptions when it comes to SOC audits:
• Misstatements: a misstatement is used to refer to an error or omission in the description of the service
organization’s system or services.
• Deficiency in the Design of a Control: a design deficiency is used when a control necessary to achieve
the control objective or criteria is missing or an existing control is not properly designed, even if the
control operates as designed, to achieve the control objective or criteria.
• Deficiency in the Operating Effectiveness of a Control: an operating deficiency is used when a properly
designed control does not operate as designed or when the person performing the control does not
possess the necessary authority or competence to perform the control effectively.
As your instinct would suggest, an exception is not a good thing. However, having an exception does not
necessarily mean that a control fails, nor does a control failure mean that an objective or criteria is not met.
It is actually quite common for a SOC report to have some exceptions. Some user entities and auditors
reading an audit report actually like to see one or two exceptions in a report because it gives them some
comfort that the auditor is doing a thorough job.
Review Audit Exceptions for Errors

It is important for you to review any audit exceptions. Auditors may mistakenly believe an error has occured
because they:
• misunderstood the documentation provided;

• did not ask the right question; or
• did not ask the right person.
Spending a little time with your auditors to understand the exceptions and confirming them internally
can pay big dividends. In some cases, you will be able to find and provide the “missing” evidence to your
auditors who can clear the exceptions. In other cases, you may be able to identify another control activity
that your organization performs that mitigates the risk. Often, the risk raised by an audit exception is
mitigated by other controls within the environment.

Stay Diligent When Reviewing Audit Exceptions
Try not to get bogged down in the weeds when discussing audit results with your auditors. If there are
control exceptions, ask them:
• Does the exception constitute a control failure?

• If there is a control failure, was it a design or operating deficiency?
• Do any of the deficiencies that impact, in their opinion, the organization’s ability
to meet their control objectives or criteria specified for the audit?
• Do they feel that the exceptions or deficiencies, individually or collectively,
could result in a qualified opinion on the audit?
These questions will allow you to understand just how bad the exceptions are. You don’t really need to worry
about a variance that will be noted in the report, but is not considered a control failure. If a control has an
exception, knowing if it is a design or operating deficiency will help you understand what type and level of
corrective action is needed.
Qualified vs. Unqualified Opinions

Another important pair of terms to keep straight when discussing audit results are ‘qualified’ and
‘unqualified.’ Unlike how most uses of these terms has ‘qualified’ as a positive term and ‘unqualified’ as a
negative, auditors use them differently.
For example, we are qualified for jobs. However, we auditors like to be different. So, your ultimate goal in
audit is to get an unqualified or clean opinion. A qualified opinion is not good in that it means that there is at
least one control objective or criteria that the auditor believes the organization was not able to achieve.
No matter how serious or not serious the exceptions may be, remember to always ask your auditor what
they might recommend that you do to correct the exception(s) going forward.
Conclusion
Hopefully this helped you better understand the purpose and process of an audit, what audit exceptions are,
and clarified what to look for when discussing the results of an audit.

What is a SOC 1 Report? Expert Advice You Need to Know
At Linford and Company, we hear this question all the time, “what is a SOC 1 report?” For decades there
has been a trend in outsourcing certain aspects of running organizations to other organizations. The value
proposition for an organization is simple, organizations can focus on what they do best and leave some of
the other details required to run their organization up to other organizations (in CPA jargon these are called
service organizations). A SOC 1 (f. SSAE 16) Report (Service Organization Controls Report) is a report on
controls at a service organization which are relevant to user entities’ internal control over financial reporting.
Who Needs a SOC 1 Report? Example: Service Organization (Payroll Processing)

An example of a service organization that may need a SOC 1 report is a company that provides payroll
processing services to user entities. User entities that use the payroll processing company realize the
material impact of payroll on their financial statements and request some independent assurance that their
payroll is being handled in accordance with their expectations. A SOC 1 report provides user entities of
the payroll processing company reasonable assurance that the internal controls of the payroll processing
company are suitably designed (Type I report) or suitably designed and operating effectively (Type II report)
to provide the payroll services.

Who is Required to Have a SOC 1 Report
There are numerous service organizations that may receive SOC 1 reports. The common theme between
the service organizations should be the potential impact on user entities’ internal controls over financial
reporting (ICFR). Some examples of organizations who may receive SOC 1 reports include:
• Payroll processors
• Medical claims processors
• Loan servicing companies
• Data center companies
• Software-as-a-Service (SaaS) companies that may impact the financials of their user entities.
Type 1 or Type 2 Report

SOC 1 reports can be Type 1 (aka Type I) or Type 2 (aka Type II) reports.
Type 1 reports are as of a particular date (sometimes referred to as point-in-time reports) that include
a description of a service organization’s system as well as tests to help determine whether a service
organization’s controls are designed appropriately. Type 1 reports test the design of a service organization’s
controls, but not the operating effectiveness.
Type 2 reports cover a period of time (usually 12 months), include a description of the service organization’s
system, and test the design and operating effectiveness of key internal controls over a period of time.

SOC 1 Timeline – SAS 70 → SSAE 16 → SSAE 18
Between 1993 and 2011, the SOC 1 report was known as a SAS 70 report. Then in June 2011, the name was
changed by the American Institute of CPAs (AICPA) Auditing Standards Board (ASB) when they issued
the Statement on Standards for Attestation Engagements (SSAE) No. 16 which provides guidance for CPA
firms to report on controls at service organizations. The intent of the SSAE 16 or SOC 1 report is the same
as when it was SAS 70; to provide user organizations reasonable assurance that controls at their service
organizations, relevant to their internal controls over financial reporting (ICFR) are suitably designed and
operating effectively.
In 2017, the AICPA issued SSAE 18 which recodifies all previous attestation standards (including SSAE 16).
SSAE 18 took effect on May 1, 2017.
Restricted Use Reports

Because SOC 1 reports may contain sensitive information about service organizations, they are considered
restricted use reports and should only be shared with management of the service organization (the
company who has the SOC 1 performed), user entities of the service organization (the service organization’s
clients) and the user entities’ financial auditors (user auditors). The report can assist the user entities’
financial auditors with laws and regulations like the Sarbanes–Oxley Act.
When is a SOC 1 Report Required?

Most of the time, your clients will let you know when a SOC 1 or other SOC report is required. Let’s be
honest, no one likes to go through an audit. Also, the fees for SOC audits are not insignificant, so ensuring
your clients/user entities need the report is a good way to know whether a SOC 1 is the right report for your
company. SOC 1 reports can also be a good way to differentiate the services provided to your clients vs.
those provided by a competitor without a SOC 1 report.
The abundance of information security questionnaires sent by user entities is enough to drive many
companies to obtain a SOC 1 report to answer many of the common questions. Some individuals at service
organizations spend a significant portion of their time answering questionnaires with slightly different
questions. A SOC 1 report may sometimes be provided in lieu of answering certain sections of the due
diligence questionnaires.

SOC 1 Report Structure
The Opinion Letter (SOC 1 Qualified Opinion vs. Unqualified)

The first section contains the opinion letter (aka Independent Auditor’s Report). The opinion letter outlines
the scope of the report (services included), test period (Type 2), or report as-of-date (Type 1) and type of
opinion being issued. See a related Linford&Co blog post on qualified report opinions for more information.
Management’s Assertion
The second section contains an assertion written by management of the service organization that makes
a number of management statements including the following: 1) An assertion that the description of the
system fairly presents the system, 2) The control objectives were suitably designed (Type 1) or suitably
designed and operating effectively (Type 2), and 3) Discussion of the criteria used to make the assertion.
Description of the System

The description of a service organization’s system is a description of the services provided that are relevant
to user entities ICFR. The description includes the supporting processes, policies, procedures, personnel, and
operational activities that constitute the service organization’s services that are relevant to user entities.
Description of Tests of Controls and Results of Testing

This is the section that a SOC auditor uses to describe the controls that were tested as part of the
examination, the test procedures used for testing the controls and the results of testing. When reviewing
a SOC 1 report, the opinion and the results of testing sections contain the key information necessary to
determine whether a service organization’s system of internal controls is suitably designed and operating
effectively to provide the services.
Other Information
Some SOC 1 reports include a section used by service organizations to provide additional information about
relevant processes that were not tested within the report such as disaster recovery and business continuity
information. The SOC auditor will not express an opinion on the statements made by management within
this section.
SOC 1 vs. SOC 2 vs. SOC 3 Reports

We have prospective clients that struggle whether the should get a SOC 1, SOC 2, or SOC 3 report all of the
time. We normally start by asking these prospective clients about the type of user entities asking for the
report as well as the type of services they provide to their clients. This allows us to assess whether there
may be an impact to the ICFR of prospective clients’ user entities. See these related blog posts on choosing
between SOC 1 vs. SOC 2 vs. SOC 3.

Summary
In this section, we described what a SOC 1 report is, the types of service organizations that might need a
SOC 1 report, differences between Type 1 and Type 2 reports, restricted use reports, when a SOC 1 report
might be required, the structure of a SOC 1 report, and differences between SOC reports.

SOC 1 (f. SSAE 16) Review Guidance
Many U.S. companies receive SOC 1 reports, which were previously referred to as SSAE 16 reviews, from
certain types of vendors/service organizations. SOC 1 reports are a review of the service organization’s
controls in support of the audit of a client’s financial statements. These reports are typically issued once a
year in the late fall.
While most organizations do a good job of recognizing the need to request these reports from service
organizations they use, often they are not properly reviewed and evaluated when received. So, what do you
do with the SOC 1 report once it has been received other than give it the internal and external auditors?

Common Questions on SOC 1 (f. SSAE 16)
Before we dive into how to review a SOC 1 (f. SSAE 16) report, let’s go over some common questions users have.
Many users ask if a SSAE 16 is the same as a SOC 2 report? The answer to that is: no. A SOC 1 report was
previously referred to as a SSAE 16 review and there are distinct differences between a SOC 1 and a SOC 2.
A SOC 1 (f. SSAE 16), as mentioned above, is a review of controls in support of a client’s financial statements.
The control objectives included in a SOC 1 report are most likely related to Information Technology and
Business Processes.
So what is a SOC 2 report? A SOC 2 report focuses on non-financial controls, specifically on the Trust
Services Criteria. These criteria relate to security, availability, confidentiality, processing integrity, and privacy
of the service organization’s system. Please refer to our service page on our website for further details
regarding a SOC 2 audit.
Critical Areas for Review

The following are suggestions for reviewing SOC 1 reports (f. SSAE 16):
Report Topic: Many service organizations issue multiple SOC 1 reports for the various products they offer.
Review the title and system description to determine whether the report is in support of the product your
organization is using.
Report Dates: More than a few service organizations try to pass off old reports as current reports. Make
sure you are provided with the current report. Additionally, make sure the time period covered by the report
meets your needs. Does the performed testing cover the design and operating effectiveness of the controls
over a period of time (Type II) or a point in time (Type I)? If the report timing doesn’t provide you with the
coverage you require, ask the service organization about it.

Service Auditor: The name of the service auditor issuing the SOC 1 report is typically located in Section I
of the report. Do some research on the service auditor issuing the report and determine whether they are a
reputable firm. Good resources to review are the AICPA’s website, where peer review reports can be found,
and the website of the state accountancy board, such as the Colorado Department of Regulatory Agencies –
DORA. If you don’t find any information on the service auditor after performing a search on these or related
sites, discuss your concerns with the service organization.
Auditor Opinion: In the first section of the report, the opinion of the service auditor can be found. This
opinion will outline the scope of the report and whether the report is qualified or unqualified. If the report is
qualified, your organization will need to evaluate how this qualification impacts your reliance on the report.
Learn more about qualified opinions.
Management’s Assertion: Management is required to include their written assertion in the report stating the
report’s accuracy. In some instances, SOC 1 reports are being issued without a management assertion or the
content of the management assertion differs from the auditor’s opinion. If it’s missing or opinions differ, a
conversation with the service organization is warranted.
Location: Service organizations often have multiple locations, which is to be expected in the global
economy. Make sure the report and audit testing covers the locations in which the vendor is performing
services for your company. The locations covered can often be found in the system description of the report,
and if it is not obvious, ask the service organization to clarify.
Processes, People, & Systems: The processes as well as the people and systems that support the processes
should be adequately described in the report. Make sure there is sufficient detail so you can understand
what the service organization is doing and what they are not doing. If a key process (eg, information
security) is not described in the report, ask the service organization about it.
Subservice Organizations: In some instances, a service organization relies on a subservice organization to

provide a portion of their services to the user entity. If a subservice organization is being used, determine
whether the carve-out method or inclusive method is being used. If the carve-out method is being used,
the services provided by the subservice organization and the related controls over the services provided
are not included in the scope of the SOC 1 report. If this is the case, you may need to request a SOC 1 report
from the subservice organization if the services they provide are material to your evaluation of the control
environment. If the inclusive method is being used, the services provided and the controls at the subservice
organization level are included in the scope of the SOC 1 report. If any questions arise regarding the
subservice organization, the services they provide and what is being covered in the report, clarify with the
service organization.

Complementary User Entity Controls (CUECs): Complementary user entity controls (CUECs) are controls
at the user entity level of the service organization. When reviewing a SOC 1 report, the organization needs
to review the CUECs to determine whether they are performing the controls listed. Most SOC 1 reports
have CUECs listed within them. Make sure your company considers these carefully. Learn more about
complementary user entity controls.
Testing Procedures and Results: Based on whether the SOC 1 report you are reviewing is a Type I or Type
II report, you will need to review the extent of testing performed and determine it is sufficient to meet your
organizations needs. The controls tested, the description of the testing performed and the results of the
testing can generally be found in Section IV of the report. Review any findings/issues identified, including
how they were mitigated and/or remediated, and determine how they impact your organization.
Summary
In this section, we covered various different areas in a SOC 1 (f. SSAE 16) report that could be considered
when reviewing it. There are different concerns to consider when reviewing a SOC 1 report and the lens
in which you review your SOC 1 report through should reflect the coverage you need to obtain for your
organization.
Often times, dialogue with the service organization is required in order to clarify any questions regarding the
scope and results of the report. Reviewing the report yourself, rather than just passing it off to the internal
and external auditors, is important in order to understand the services being provided, the effectiveness of
the service organization’s controls and how it impacts your organization.

Gap or Bridge Letters for SOC 1 Reports
This section is going to answer common questions related to SOC 1 (formerly SSAE 16 or often misnamed
SSAE 18) gap/bridge letters. Common questions include:
• What are bridge letters?

• How long can the coverage be for a bridge letter?
• What does a bridge letter look like?
Background: SOC 1 Timing & Dates

Astute observers will note that most SOC 1 reports often cover only a portion of the user organization’s
calendar or fiscal year. For example, a report may have a coverage date of October 1, 2018 through
September 30, 2019. If the user organization has a calendar year-end, what does the user organization do to
get comfort (e.g., an understanding) about the internal control environment for the last three months of the
year? It would be easier if the report just covered the calendar year…right?
Well, yes, it would be easier; however, most user organizations and especially their auditors (user auditors)
want the SOC 1 reports while they are doing their interim internal control testing. This testing often occurs in
the quarter prior to the user organization’s calendar or fiscal year-end.
For example, if a user organization has a calendar year-end of December 31 and this user organization is also
an SEC registrant, the interim internal control testing will be performed by the user organization’s external
auditor (e.g., Big Four accounting firm) sometime during the 3rd and/or 4th calendar quarter. Or in other
words, this interim testing will occur right before Christmas.

In the typical scenario noted above, the service auditor prepares a report ending September 30 and the user
auditors (e.g., Big Four) are doing their interim work before Christmas. In this typical scenario, the service
organization has a gap, which is defined as the period between the report end date and the end of the user
organization’s calendar year. The gap may be one or more (e.g., three) months. This of this like you would a
gap in the road. What do we need when there is a gap in the road? A bridge, but in this case, not an actual
bridge, the service organization needs a bridge letter.
What is a Bridge Letter?

A bridge letter—also known as a gap letter—is simply a letter that bridges the “gap” between the service
organization’s report date and the user organization’s year-end (i.e., calendar or fiscal year-end).
This letter is a great tool that can be used by service organizations instead of making their clients (i.e., user
organizations) wait for the next report, which in any case might require waiting another 12 months. This
letter is on the service organization’s letterhead and typically signed by the service organization.
The bridge letter is never on the service auditor’s letterhead nor is the bridge letter signed by the service
auditor. Since the service auditor is not opining—or in other words attesting—on those internal controls
within the gap period, the service auditor cannot issue the letter. Once the service auditors have issued their
SOC 1 report, the service auditors do not know definitively if the internal control environment has materially
changed or not. However, management of the service organization knows or should know this information.
There are several key points that should be addressed in the letter. Namely, the report end date, material
changes in the internal control environment (if any), a statement that the service organization is not
aware of any other material changes, a reminder that user organizations are responsible for following the
complementary user entity controls—sometimes referred to as client control considerations or user control
considerations—a request for user organizations to read the report, and a disclaimer that the bridge letter is
not a replacement for the actual SOC 1 report.

How Long Can the Coverage be for a Bridge Letter?
The answer to this question really depends on the user auditor. Most Big-Four audit firms would like to see a
bridge letter that covers a period of not more than three months. We’ve seen service organizations ask for nine
month bridge letters. That is what we might call…a bridge too far. If service organizations are finding that the
report period for their examination is not meeting their users requirements from a timing standpoint, it may be
worth the service organization revisiting the examination period with the service auditor.
What Does a Bridge Letter Look Like?

We have seen supremely complex Gap Letters, and ones that are so simple that they do not really meet the
requirements of user organizations. To aid service organizations, we have put together a couple templates
that cover all of the key points in a bridge letter and should meet the requirements of discerning user
organizations. Use these gap letter examples as your own gap/bridge letter templates.

SOC 1 vs. SOC 2 – What is the Difference and How do you Know What you Need?
Many of our clients and prospects get asked for a “SOC report” without any further clarification. Also, many
get asked for a SOC 1 and a SOC 2… so how do they know what they need? Do they need both? Just one?
We get these questions all the time, and with a quick conversation, we can generally sort out what is really
needed based on the services the organization is providing and who is asking for the report. The following
information may help your organization determine which report is right.
What is a SOC Report?

SOC stands for “System and Organization Controls.” These were formerly Service Organization Control
reports. SOC is a suite of reports from the AICPA that CPA firms can issue in connection with system-level
controls at a service organization. Currently there is a SOC 1, SOC 2, SOC 3, and SOC for Cybersecurity
report offering. In addition, there are SOC + reports where another standard can be added (i.e. HIPAA,
HITRUST, NIST, etc.). The AICPA is working on additional offerings, with the next report offering being SOC
for Vendor Supply Chain.
While there are a number of offerings of SOC reports from the AICPA, we will focus on SOC 1 and SOC 2, as
these are the most common from the SOC suite.

What is the Difference Between a SOC 1 and a SOC 2 Report?
SOC 1 Reports: A SOC 1 report falls under the Statement on Standards for Attestation Engagements (SSAE)
18 AT-C 320 (formerly SSAE 16 or AT 801), though is named a SOC 1 versus the name of the standard
(reports are NOT called SSAE 18s). The SOC 1 report focuses on a service organization’s controls that are
relevant to an audit of a service organization’s client’s financial statements. The service organization will
determine the key control objectives for the services provided to clients. Control objectives are related to
both business process and information technology process at the service organization. A SOC 1 Type I report
includes a description of controls (design) at a service organization’s as of a specific date. A SOC 1 Type II
report contains the same opinions on the design of controls, but it additionally includes an opinion on the
operating effectiveness of controls over a period of time. The SOC 1 report addresses internal controls
relevant to an audit of a service organization’s client’s financial statements. Readers of SOC 1 reports could
include financial executives at a user organization, compliance officers, and financial auditors of the service
organization.
SOC 2 Reports: A SOC 2 report also falls under the SSAE 18 standard, though is specifically addressed in
sections AT-C 105 and AT-C 205. The SOC 2 report addresses a service organization’s controls that are
relevant to their operations and compliance, as outlined by the AICPA’s Trust Services Criteria (TSC). The
available TSCs include security, availability, processing integrity, confidentiality, and privacy. The security TSC
is the only required TSC in the SOC 2. Controls meeting the TSCs included in the examination are identified
and tested, versus in a SOC 1 where controls supporting identified control objectives are tested.
For additional information on the available TSC’s please see the following blog posts:
• Security
• Availability
• Processing integrity
• Confidentiality
• Privacy

A service organization can choose a SOC 2 report that focuses on just the security TSC or all five TSCs, or a
combination or the five TSCs available. The readers of SOC 2 reports can also be an organization’s financial
executives, compliance officers, and financial statement auditors, but can also include an organization’s
information technology executives, business partners, regulators, or other business partners.
To Summarize the Comparison of SOC 1 vs. SOC 2:

• The SOC 1 report addresses internal controls relevant to an audit of a service organization’s client’s
financial statements.
• The SOC 2 report addresses a service organization’s controls that are relevant to their operations and
compliance, as outlined by the AICPA’s Trust Services Criteria (TSC).
What is the Difference Between a Type I and a Type II in a SOC Report?

We discuss above the difference between a SOC 1 and a SOC 2, but within each of these examinations, the
reports can be a type I or a type II.
A type I examination looks at the description or design of controls as of a specified date. The report for a
type I includes the same sections as the type II, there is just no testing included outside of a test of one to
confirm the description or design of controls.
A type II examination also looks at the design of controls, but also includes testing of the operating
effectiveness of controls over a period of time. A type II report covers a minimum of six months (there are
exceptions to this, but as a general rule six months is the minimum). The goal of an organization is to have
the type II cover 12 months and then have annual type II reports to have continuance coverage of controls.
If a service organization needs to get an initial report to a client or prospect quickly, the initial report can
be a type I to show evidence of controls in place. If there is not a rush to get an initial report out quickly, we
generally recommend starting with a type II.

Do Some Service Organizations Need Both a SOC 1 and SOC 2?
There are instances when a service organization gets asked for and receives both a SOC 1 and SOC 2
examination. We have a number of clients that provide services that span across different industries and
therefore get asked for a SOC 1 from some of their clients and a SOC 2 from other clients. There can be
overlap in the testing included in the reports, which can provide efficiencies in testing.
Summary
A SOC 1 report is designed to address internal controls over financial reporting while a SOC 2 report
addresses a service organization’s controls that are relevant to their operations and compliance. One or both
could be right for your organization. At Linford & Company we can help determine the correct report or
reports to meet your needs.

Testing Procedures and Results During a Type II SOC 1 or SOC 2 Engagement
Type II engagements (for both SOC 1s and SOC 2s) require walkthroughs and testing of the controls in
place at the service organization to be able to opine on the suitability of the design and the operating
effectiveness during the period under review. Each control objective has a number of supporting controls
that are walked through and tested, and this is accomplished using a variety of testing methods.
There are four main methods to walkthrough and test each control in place at the service organization.
These methods include (listed in order of complexity): inquiry, observation, examination or inspection of
evidence, and re-performance.
• Inquiry: Simply, the auditor asks appropriate management and staff about the controls in place at the
service organization to determine some relevant information. This method is often used in conjunction with
other, more reliable methods. For example, an auditor may inquire of management if visitors to the data
center are escorted at all times if the auditor is not able to observe this activity while on site. No control
objective should ever be supported by controls only tested through inquiry procedures.
• Observation: Activities and operations are tested using observation. This method is useful when there
is no documentation of the operation of a control, such as observing that a security camera is in place or
observing that a fire suppression system is installed.

• Examination or Inspection of Evidence: This method is used to determine whether or not manual controls
are being performed. For instance, are backups scheduled to run on a regular basis? Are forms being
filled out appropriately? This method often includes reviewing written documentation and records such as
employee manuals, visitor logs, and system databases.
• Re-performance: This method is used when the other three methods combined fail to provide sufficient
assurance that a control is operating effectively. This method of testing is the strongest type of the four.
This requires the auditor to manually execute the control, such as re-performing a calculation that a system
automatically calculates.
Samples of populations are selected for testing based on the type of test being performed (i.e., a test of one
would be completed for an automated control using re-performance, but a sample of the population would
be selected for an inspection control), the population size, and the level of precision we want to achieve.
If, during testing, the auditor encounters an error in a test of controls, they will expand the sample size and
conduct further testing, or perform additional tests. If additional errors are found, the auditor will consider
whether there is a systematic controls problem that renders the controls ineffective, or if the errors appear
to be isolated instances that do not reflect upon the overall effectiveness of the control in question.
The results of these testing procedures are documented within the final SOC 1 section, “Independent Service
Auditor’s Description of Tests of Controls and Results” or the SOC 2 section, “Independent Service Auditor’s
Description of Tests of Controls, Control Criteria, and Results.” The type of test performed and the results of
testing are listed with the control. If there are findings listed in the report, a management response is
also included.

What is a SOC 2 Report? Expert Advice You Need to Know
In this section, we will cover some common questions that come up related to SOC 2 reports. SOC 2
compliance does not have to be difficult although with some of the terminology, it can initially be confusing.
So what are SOC 2 reports and examinations? Let’s dive in!
What is SOC 2 Certification or Attestation?

While there is no such thing as a SOC 2 certification, many still refer to a SOC 2 certification. One of our
clients recently received a request from a prospective client asking whether they were a SOC 2 certified data
center. Our client, being more savvy than most, said, “We don’t have a SOC 2 certification. We have a SOC 2
attestation.” Our client’s prospect, or user organization, in SOC language, wanted to hop on a call to discuss.
The prospect was considering backing out of the deal because our client was not SOC 2 “certified.” We
joined on the call and told our client’s prospect that our client did in fact have a SOC 2 report, but they were
not SOC 2 “certified.” The prospect then said, “oh, so you are SOC 2 certified” and the deal moved forward.
We laughed afterwards with our client because our client’s prospect could not grasp the terminology.

What is a SOC 2 Report?
SOC 2s differ from some other information security standards and frameworks because there is not a
comprehensive list of “thou shalt” requirements. Instead, the AICPA provides criteria that can be selected
by a service organization to demonstrate they have controls in place to mitigate risks to the service they
provide. This can be a bit annoying for some first time clients since there isn’t one right answer for how to
address the applicable criteria. Instead, a good auditor’s job is to identify what is already being done by
their clients to meet the applicable criteria. In some cases, there are gaps and clients must implement new
controls. In other cases, existing controls need to be tweaked slightly to better address the criteria. Our goal
is for our clients to meet the criteria selected, but to create the least impact and additional overhead when
remediating controls as possible.
SOC 2 reports are considered attestation reports. For a SOC 2 attestation, management of a service
organization asserts that certain controls are in place to meet some or all of the AICPA’s SOC 2 Trust
Services Criteria (TSC). Management also selects which of the five TSCs best address the risk of the services
provided by the service organization.
See the AICPA website for more information on attestation reports.
When a service organization completes a SOC 2 report, the report contains an opinion from a CPA firm that
states whether the CPA firm agrees with management’s assertion. The opinion states that the appropriate
controls are in place to address the selected TSCs and the controls are designed (Type I report) or designed
and operating effectively (Type II report). In many cases, the opinion is positive and the CPA firm agrees
with management’s assertion. In other cases, the CPA firm does not agree with management’s assertion and
provides a qualified or adverse opinion. See our blog post on qualified opinions.

What Does SOC 2 Stand For?
A SOC 2 is a System and Organization Control 2 report. There are three types of SOC reports. See this
AICPA whitepaper comparing the reports. Some companies struggle with the differences between SOC
reports, and whether they should get a SOC 1, SOC 2, or SOC 3. We start by asking prospective clients about
the type of clients and stakeholders asking for the report as well as the type of services provided to clients.
This allows us to assess whether prospective clients may impact the internal controls over financial reporting
(ICFR) of our prospective clients’ user organizations.
If a service organization can impact the ICFR of its user organizations, a SOC 1 report may be the best report
option. If a service organization cannot impact its user organizations’ ICFR, but they can impact the security,
availability, processing integrity, confidentiality, or privacy of their user organizations, then a SOC 2 may be
the best report for the service organization’s clients.
SOC 2 Report Structure

The SOC 2 report structure is similar to a SOC 1 report structure, which we outlined in our SOC 1 article, and
consists of:
• The Opinion Letter

• Management’s Assertion
• Description of the System
• Description of Tests of Controls and Results of Testing
• Other Information

Who Needs a SOC 2 Report?
Service organizations that do not materially impact the ICFR of their user organizations, but do provide key
services to user organizations may need a SOC 2 report.
SOC 2 Report Example

Many companies outsource IT infrastructure to service organizations, such as data centers and cloud hosting
providers (e.g., Amazon’s AWS). What do these service organizations do to prove to clients and stakeholders
that they are adequately protecting their servers and sensitive data? Service organizations receive SOC 2
reports to demonstrate they have certain controls in place to mitigate security, availability, confidentiality,
processing integrity, or privacy risks. A SOC 2 report will include a CPA firm’s opinion on controls design and
potentially operating operating effectiveness over a period of time.
Using AWS as an example, many companies use AWS and request assurance from AWS that there are
controls in place to mitigate the risk of AWS’ systems and data being compromised. AWS could attempt to
provide different answers to every single client that asks security related questions, but that would take too
much time. Instead, AWS has selected an independent CPA firm to perform a SOC 2 examination (among
many other AWS compliance exams). Then, rather than respond to all the questions regarding AWS’ security
posture, AWS provides its SOC 2 report, which answers many of the common questions asked by its user
organizations related to security, availability, confidentiality, processing integrity, and privacy.
Learn more in our article, Leveraging the AWS SOC 2: How to Build a SOC 2 Compliant SaaS.

What is SOC 2 Compliance? The Trust Services Criteria (TSC)
A service organization should choose the SOC 2 TSCs that mitigate the risk of their user organizations use
of the service organization’s services. At a minimum, SOC 2 reports must include the Security or Common
Criteria. The other TSCs can be added depending on the needs of user organizations.
Recently, we had a prospective client say they wanted all of the TSCs included within their report because
they wanted it to be the strongest report possible. Unfortunately, not all TSCs may apply to a particular client’s
service. For example, if your company does not process transactions, processing integrity is probably not
applicable. I’ve heard of firms including TSCs when they are not applicable within a report and then explaining
why they are not applicable within the report. That’s not advised. Your best bet is to select criteria that is
applicable to your services and answer the questions you hear most from your clients and prospective clients.
The Trust Services Criteria are noted below:

• Security – The system is protected against unauthorized access (both physical and logical).
• Availability – The system is available for operation and use as committed or agreed.
• Processing Integrity – System processing is complete, accurate, and authorized.
• Confidentiality – Information that is designated “confidential” is protected according to policy or agreement.
• Privacy – Personal information is collected, used, retained, disclosed, and disposed of in conformity with
the commitments in the entity’s privacy notice and with criteria set forth in Generally Accepted Privacy
Principles issued by the AICPA.
Other Common Questions About SOC 2 Reports

Is There a SOC 2 Checklist?
There is no checklist, but the AICPA’s SOC 2 criteria can be obtained and reviewed. So how do you get it?
You can buy it from the AICPA or contact us for a consultation. The criteria contains requirements related
to each of the TSCs outlined above. The requirements may be met in a variety of ways, so there is not
a one size fits all checklist for SOC 2 compliance. It is dependent on the services provided by a service
organization. The SOC 2 criteria is also going through an update. See our blog post on the updated SOC 2
criteria which now more closely aligns with COSO.

How Much Does a SOC 2 Report Cost?
SOC 2 examinations are not cheap and fees depend on a number of factors. Factors include the scope of
services included within the report, the TSCs included, the size of the organization, and the number of in
scope systems and processes. For example, if a company has three different patch management processes
to ensure servers and workstations stay up-to-date, the auditor will need to gain assurance that each of
those processes is designed operating effectively. Learn more in our article, How Much Does A SOC Audit Cost?
Who Can Perform a SOC 2 Audit?

Licensed CPA firms that specialize in information security audits are the only organizations that should
perform SOC 2 examinations. There are some companies that perform SOC 2 audits and have a CPA firm
sign off on their report even though the CPA firm did not perform the audit. We recommend staying away
from that approach. We also recommend selecting a firm that has experienced IT auditors and not financial
audit CPAs only. When selecting a firm to perform a SOC 2, we recommend asking for the resumes or
bios for any of the auditors that will complete the work. Then, ensure the firm you select has auditors with
the appropriate skills and expertise. Certifications such CISA or CISSP are good to look for. Also, check
references and ensure the firm you select has experience in the field you are in.
Updated SOC 2 Guidance

On December 15, 2018, new SOC 2 guidance went into effect and all reports following that date must include
the updated criteria. See our previous blog post related to the latest SOC 2 criteria update.
Achieve SOC 2 Compliance For Your Organization

If you have questions on which TSCs to include in your SOC 2 or what the process for receiving a SOC 2
audit entails, please contact us to request a consultation.

First time SOC 2 Audit: What to Expect
So you have begun to be asked by a current client or prospective client for a SOC 2 report. What now?
First, identify a firm with expertise in performing SOC 2 audits, not just a traditional CPA firm that
moonlights when performing SOC 2 audits. Ensure the firm uses IT auditors with a background in
information security. Common IT auditor certifications are the Certified Information Systems Auditor (CISA)
and Certified Information Systems Security Professional (CISSP).
Next, determine whether your clients or prospective clients will need a type I or type II report.
Most user organizations (SOC 2 report stakeholders) who request a SOC 2 report will accept a Type I report
for the first year. If your user organization needs a Type II report immediately, engage a firm who can perform
a pre-assessment right away to identify any gaps against the desired SOC 2 criteria for the desired AICPA
Trust Services Principles (Security/Common Criteria, Availability, Confidentiality, Processing Integrity, Privacy).
Once any gaps identified within the pre-assessment are remediated, a six month examination period can begin.
Once the six months has passed and all of the controls tested as part of the audit are found to be operating
effectively for the six month period, a six month Type II report with a clean audit opinion can be issued. For
following years, the examination period is almost always adjusted to twelve months.

For the following example, let’s assume that your user organization will accept a Type I SOC 2 report for the
first year. What can you expect next?
1. Receive a letter from your firm that you can share with your user organization(s) letting them know the s
cope of the SOC 2 audit to be performed and when they can expect to receive the final report.
2. Receive an initial request list, illustrative risk and control matrix to help facilitate completion of the pre-
assessment and performance of walkthroughs to identify key controls within each in scope process.
3. Schedule a week or more of on-site fieldwork. Length of fieldwork is dependent upon the size of the
company and scope of the SOC 2 audit.
4. Schedule a meeting (in person or remotely) with your audit firm to go through the initial request list and
illustrative control matrix. The documents are used to generate conversation around the actual controls that
are in place vs. the hypothetical controls in the illustrative risk and control matrix.
5. Identify any gaps based on the discussions with your audit firm against the desired AICPA Trust Services
Principles and Criteria.
6. Remediate any identified gaps and provide evidence to your auditor that the gaps were remediated.
7. Perform on-site audit fieldwork to ensure that controls are designed appropriately as of a point in time
such as July 31, 2019.
8. Discuss any potential issues identified in the report and gain agreement with your audit firm on any issues
that are included in the report.
9. Obtain and review the draft Type I SOC 2 report.
10. Obtain the final Type I SOC 2 report after any feedback is incorporated.
11. Obtain Type II SOC 2 reports for following years.

Trust Services Criteria (formerly Principles) for SOC 2 in 2019
In recent years, the AICPA has made updates to what is required to be covered in a SOC 2 examination.
Previously called Trust Services Principles, or Trust Services Principles and Criteria, the AICPA has dropped
“Principles” and now just calls them Trust Services Criteria. The AICPA did not change the acronym for the
codification of the guidance, as the criteria are still referred to as TSP in the guidance and can be found at
TSP section 100.
The previous trust services principles (2016 TSPs) and criteria were effective starting December 15, 2016. The
updated trust services criteria were required to be used on any report issued on or after December 15, 2018.
Currently, any reports being issued should be referencing and mapping to the 2017 trust services criteria.

What are the Five Trust Services Criteria (formerly Principles)?
Though the AICPA changed the name, there are still five criteria that are available to be included in a SOC
2 examination. The five criteria and the definitions did not change with the updated 2017 guidance. The five
criteria are listed below (with links to articles on each criteria)
• Security
• Availability
• Confidentiality
• Privacy
• Processing Integrity
The only criteria that is required to be in a SOC 2 examination is the security criteria, which is also known
as the common criteria. The security criteria is referred to as common criteria because many of the criteria
used to evaluate a system are shared among all of the Trust Services Criteria.
For example, the criteria related to risk management applies to four of the criteria (security, processing
integrity, confidentiality, and availability). The common criteria establishes the criteria common to all the
trust services criteria and the comprehensive set of criteria for the security criteria.
When a service organization’s client wants to know their information/data is secure and protected, they are
likely interested in the security criteria. This criteria is comprehensive enough that including it in the scope of
the examination alone will likely be enough for service organization’s clients to get the assurance they need
with respects to the security of their information/data.
The other available criteria can be added to the examination at the discretion of management, or if it is
determined that the criteria is key to the services being provided.
Prior to deciding on the criteria to include in the SOC 2 examination, the service organization, with the help
of their auditor, should determine the system and its boundaries relevant to the services that are being
provided. This should include contemplation of the entire environment, including software, infrastructure,
procedures, data, and people. After the scope of the examination has been determined, it can then be
decided which of the criteria are pertinent to the service organization’s services and system.

Which Criteria do you Include in your SOC 2?
Determining which of the criteria to include in the scope of a SOC 2 examination is a key step in the SOC
2 planning process. A service organization should do their homework and know a little about the available
criteria and if they apply to their services and system. It is also very important to get advice from an
experienced accounting firm that can help navigate through the criteria and determine which ones are relevant.
Helping determine the criteria to include, as well as determining the boundaries of the system is something
at Linford & Company that we do all the time as part of our SOC 2 audits.
How do the 17 COSO Principles Integrate with the SOC 2 Criteria?

Widely recognized, the 2013 COSO Framework is used a lot to evaluate the design and operating
effectiveness of an entity’s internal controls. Because both COSO and the trust services criteria are used to
evaluate internal control, it made a lot of sense to integrate them. COSO is made up of 17 principles which
are grouped into the following five categories:
• Communication and Information

• Control Environment
• Monitoring Activities
• Risk Assessment
• Control Activities
These five categories align with the first five criteria sections within the security/common criteria section.

Additional SOC 2 Criteria Outside of the COSO Principles
The following guidance is included in COSO Principle 12: “The entity deploys control activities through policies
that establish what is expected and procedures that put policies into action.” The 2017 Trust Services Criteria
describe specific criteria in additional to the COSO principles that are mapped in to evaluate the internal
controls over the five trust services criteria. TSP Section 100.05 describes the additional criteria as follows:
• Logical and physical access. How an entity restricts access (physical and logical), adds and removes said
access, and avoids unauthorized access.
• System operations. How an entity manages the operation of system(s) and detects and mitigates
processing nonconformities, including access (physical and logical) security nonconformities.
• Change management: How an entity recognizes the necessity for changes, executes the changes using a
controlled process and stops unauthorized changes from occurring.
• Risk mitigation: How the entity recognizes, chooses, and advances risk mitigation activities that have
occurred from business disruptions, and the monitoring and evaluation of the use of business partners
and vendors.
Points of Focus in a SOC 2

Points of focus are new to SOC reporting with the 2017 trust services criteria but have been part of the
COSO framework previously. For each of the criterion, there is a list of several associated points of focus.
The points of focus deliver details as to the features that should be included in the design, implementation,
and operation of the control related to the criterion. There are around 200 points of focus associated with
the SOC 2 common criteria in the 2017 Trust Services Criteria. For all five categories (security, availability,
processing integrity, confidentiality, and privacy) where the COSO principles map in, there are 61 criteria with
almost 300 points of focus.
The numbers listed in the previous paragraph should not cause any alarm, because a majority of the points
of focus are what SOC auditors should be reviewing already as part of the SOC 2 examination. The points
of focus have not been listed with the criteria until the 2017 update. Additionally, not all points of focus
are relevant to the service provider. An assessment of whether each point of focus is met by the service
organization is not required according to the guidance at TSP 100.04.

Where to find Additional Information the Trust Services Criteria
The Trust Services Criteria can be purchased in the AICPA store. Additionally, a mapping document, which
shows how each of the 2017 criteria and points of focus relate to the COSO principles, and how they map to
the 2016 Trust Services Principles and Criteria, can be downloaded from the AICPA.

SOC 2 Security Trust Services Criteria
The Trust Services Criteria (TSC) were developed by the AICPA Assurance Services Executive Committee
(ASEC). The available TSCs for a SOC 2 audit include:
• Security (also known as common criteria). This is the only required TSC and is included to demonstrate
that systems at a service organization are protected against unauthorized access and other risks that could
impact the service organization’s ability to provide the services promised to clients.
• Availability. Included where service organizations need to demonstrate that their systems are available at
all times.
• Processing integrity. Demonstrates that system processing is occurring accurately and timely.
• Confidentiality. This TSC is included to demonstrate that data classified as confidential is protected.
• Privacy. When a service organization is in possession of personal information, this TSC is included to show
that this personal information is protected and handled appropriately.
The Security TSC is the only TSC that is required in a SOC 2. The other four criteria can be added at the
discretion of management, and should be included if the criteria are key to the services being provided by
the service organization.
What Makes up the Security/Common Criteria?

In terms of the SOC 2 Criteria, security refers to the protection of information and systems.
Protection of Information
The security TSC tests that information is secure during the collection or creation of the data, and during the
use, processing, transmission and storage of the data.

Protection of Systems
Systems in the security TSC are defined as anything that uses electronic information to process, store,
or transmit information relevant to the services provided by the service organization. Controls tested in
the security TSC are checking that there is prevention and detection to any breakdown in the security or
processing by these systems.
The security TSC is also referred to as common criteria, and is broken down into common criteria sections.
• CC1 – Control Environment
• CC2 – Communication and Information
• CC3 – Risk Assessment
• CC4 – Monitoring Activities
• CC5 – Control Activities
• CC6 – Logical and Physical Access Controls
• CC7 – System Operations
• CC8 – Change Management
• CC9 – Risk Mitigation
The AICPA guidance provides the criteria sections and then also points of focus within each of the criteria
sections. Points of focus (i.e. controls) represent important characteristics of the criteria. These are provided
by the AICPA to assist in designing controls supporting the criteria. Not all of the points of focus will be
suitable or relevant to the service organization, so they can be customized, or different points of focus/
controls can be developed to be included in the examination.
Use of all the points of focus in not required. For example, under CC4 – Monitoring Activities, one of the
points of focus is “Considers Different Types of Ongoing and Separate Evaluations—Management uses a
variety of different types of ongoing and separate evaluations, including penetration testing, independent
certification made against established specifications (for example, ISO certifications), and internal audit
assessments.“
Mapping COSO into the Common Criteria

The 17 internal control principles from the COSO framework have been mapped into the Security/Common
Criteria. COSO is mapped into the first five criteria as follows:
Control Environment
The control environment common criteria (CC1) covers COSO Principles 1-5. This criteria section covers the
service organization’s commitment to integrity and ethical values, independence by the board, management
and board oversight, and the hiring, maintaining and ongoing monitoring of quality employees at the service
organization.

Communication and Information
The communication and information common criteria (CC2) covers COSO Principles 13-15. This criteria
section includes the communication of relevant information (lines of authority, boundaries of the system,
relevant changes, etc.) to internal personnel as well as clients of the service organization.
Risk Assessment
The risk assessment common criteria (CC3) covers COSO Principles 6-9. This criteria section is included to
demonstrate that the service organization is assessing risks possibly impacting their operations and putting
plans in place to mitigate these risks.
Monitoring Activities
The monitoring activities common criteria (CC4) covers COSO Principles 16-17. This criteria covers the
ongoing evaluation of the system at the service organization and the notification to relevant personnel in the
event that there is a breakdown in the system.
Control Activities
The control activities common criteria (CC5) covers COSO Principles 10-12. This criteria section tests that
the service organization has controls in place for the mitigation of risk and also that the controls in place are
monitored on an ongoing basis.
On the AICPA website you can download the SOC 2 criteria that includes the mapping to COSO. See
Mapping of the 2017 Trust Services Criteria to Extant 2016 Trust Services Principles and Criteria. They also
offer mapping to other frameworks, including ISO 27001, NIST CSF, and COBIT5.
Summary
A SOC 2 examination includes many areas, even specific areas within the required security/common criteria.
If your organization is considering a SOC examination, or you have questions about what TSCs should be
included, please contact us to request a consultation.

Confidentiality vs. Privacy in a SOC 2
In a SOC 2 examination, there are five possible Trust Service Criteria (TSC) that can be included – two of
the five are privacy and confidentiality. These two criteria can be confusing and may seem to overlap or be
interchangeable. Often times both get talked about in the same context although their underlying definitions
are different. Privacy and confidentiality are defined in the SOC 2 audit guide from the American Institute of
Certified Public Accountants (AICPA) as follows:
• Privacy: Personal information is collected, used, retained, disclosed, and destroyed in conformity with
the commitments in the entity’s privacy notice and with the criteria set forth in generally accepted privacy
principles (GAPP).
• Confidentiality: Information designated as confidential is protected as committed or agreed.

What is the Difference Between Privacy and Confidentiality?
The main difference between privacy and confidentiality is that one protects personal information while the
other protects non-personal information and data. Personal information includes any information that can be
attributed to an identified individual, such as:
• Name
• Home or email address
• Identification number (Social Security Number, Social Insurance Number, etc.)
• Physical characteristics
• Consumer purchase history
• Information on medical or health conditions
• Financial information
• Information related to offenses or criminal convictions
The term “confidential information” and its meaning can vary between organizations or geographical
location and potentially cover a wide range of information security practices. If the service organization
has outlined contractual commitments with its clients related to the protection of information as the data
custodian, then the confidentiality principle can be considered.
Unlike personal information, confidential information is not so easily defined. Any personal or non-
personal information or data can be designated as confidential, and once it is, it needs to be protected.
Interpretations of this type of information often vary significantly from one company to another. Some
examples of confidential information include, but are not limited to:
• Transaction details
• Engineering drawings
• Business plans
• Banking information
• Legal documents
Is There a Difference Between Security and Privacy?

Security is the only TSC that is required in a SOC 2. A lot of times this is sufficient because service
organizations with possession of PII are just expected to properly secure the data from unauthorized
disclosure. The privacy TSC is needed when the service organization interacts directly with the individuals
themselves, whose personal information they process on behalf of their clients. It is necessary to
demonstrate good security practices, and therefore the privacy TSC should be included.

What is Included in the Privacy TSC?
Including the privacy TSC gives independent assurance that the service organization personnel adhere to
good privacy and data protection practices. The SOC 2 audit report including the privacy TSC includes a
CPA firm’s opinion as to an organization’s compliance with the Trust Services Criteria on Privacy, as well as
representations made in the organization’s published privacy policy or notice. The Privacy criteria should be
looked upon as a collection of processes, procedures, legal documents, and other best practices for ensuring
the safety and security of highly sensitive consumer/client data.
The framework developed by the Privacy Task Force is called the Generally Accepted Privacy Principles
(GAPP). The GAPP consists of ten privacy principles, which are reviewed as part of the SOC 2 Privacy
Criteria. The privacy principles are listed and summarized below:
1. Management. The entity defines, documents, communicates, and assigns accountability for its privacy
policies and procedures.
2. Notice. The entity provides notice about its privacy policies and procedures and identifies the purposes
for which personal information is collected, used, retained, and disclosed.
3. Choice and consent. The entity describes the choices available to the individual and obtains implicit or
explicit consent with respect to the collection, use, and disclosure of personal information.
4. Collection. The entity collects personal information only for the purposes identified in the notice.
5. Use, retention, and disposal. The entity limits the use of personal information to the purposes identified in
the notice and for which the individual has provided implicit or explicit consent. The entity retains personal
information for only as long as necessary to fulfill the stated purposes or as required by law or regulations
and thereafter appropriately disposes of such information.
6. Access. The entity provides individuals with access to their personal information for review and update.
7. Disclosure to third parties. The entity discloses personal information to third parties only for the purposes
identified in the notice and with the implicit or explicit consent of the individual.
8. Security for privacy. The entity protects personal information against unauthorized access (both physical
and logical).
9. Quality. The entity maintains accurate, complete, and relevant personal information for the purposes
identified in the notice.

10. Monitoring and enforcement. The entity monitors compliance with its privacy policies and procedures
and has procedures to address privacy related complaints and disputes.
For additional information on the 10 generally accepted privacy principles, see The 10 Generally Accepted
Privacy Principles.
‘What is Included in the Confidentiality TSC?

The Confidentiality TSC focuses on testing that information designated as confidential is protected as
committed or agreed to with clients. When testing this TSC it is important that a policy is documented
that defines the various types of data that a service organization has in their possession and how they then
handle each type of data. Specific areas of review will cover:
• Identification of confidential information: Procedures are in place to identify and designate confidential
information when it is received or created and to determine the period over which the confidential
information is to be retained.
• Protection of confidential information from destruction: Procedures are in place to protect confidential
information from erasure or destruction during the specified retention period of the information.
• Destruction of confidential information: Procedures are in place to identify confidential information
requiring destruction when the end of the retention period is reached.
Summary
In summary, there are differences between the privacy and confidentiality TSCs in a SOC 2, and it depends
on the type of data a service organization has in their possession and what they are doing with it that will
determine which (or both) TSC should be included in the examination.

Availability Trust Services Criteria in a SOC 2 Audit
The available Trust Services Criteria (TSC) as defined by the American Institute of Certified Public
Accountants (AICPA) that can be included in a SOC 2 audit are the following:
• Security. Information and systems are protected against unauthorized access, unauthorized disclosure of
information, and damage to systems that could compromise the availability, integrity, confidentiality, and
privacy of information or systems and affect the entity’s ability to meet its objectives.
• Availability. Information and systems are available for operation and use to meet the entity’s objectives.
• Processing integrity. System processing is complete, valid, accurate, timely, and authorized to meet the
entity’s objectives.
• Confidentiality. Information designated as confidential is protected to meet the entity’s objectives.
• Privacy. Personal information is collected, used, retained, disclosed, and disposed to meet the
entity’s objectives.
The only TSC that is required to be in every SOC 2 examination is the security TSC. The other four TSCs are
options to be included in the examination at the discretion of the service organization.
In this post we will look specifically at the availability criteria. For additional information on the current
SOC 2 guidance, refer to our article on the New Trust Services Criteria.

What is the Availability Trust Services Criteria?
As illustrated above, the AICPA defines the availability trust services criteria as “Information and systems are
available for operation and use to meet the entity’s objectives.”Availability is a commonly included TSC since
providing evidence that systems are available for operation is key to many clients of service organizations.
A lot of service organizations are providing an outsourced service to their clients, and most of these will have
contractual requirements or service level agreements (SLAs) in place around the services being provided.
Because of these requirements and SLAs, the availability TSC is great to include to evidence this. Data centers
and service organizations that provide software as a service (SAAS) commonly include the availability TSC.
How do I Know if my Organization Needs the Availability TSC?

Choosing the correct principles to include in the scope of a SOC 2 examination is an important process.
A service organization should be educated on the principles and the applicability they have on their system.
Having knowledge and counsel of an experienced firm that performs SOC 2 examinations is very beneficial
and will result in a more successful examination.
When we are talking to prospective (and existing) clients about which criteria to include, we generally find out
two different things. Specific to availability, we ask:
1. Is the availability of your systems key to your clients?

2. Are your clients asking for the availability TSC?
If availability is key to your clients, it should be included in your SOC 2.

For example, if the service organization is a data center, availability is certainly a key service provided,
because if the data center goes down, the client’s business will be impacted. Clients of the data center would
likely expect elements of availability of the data center included in the report. Many clients will specifically ask
that availability be included in the report.

What Additional Testing is Included in the Availability TSC?
There are three additional criteria that are tested as part of the availability TSC (see all of the criteria,
including the below availability criteria in the AICPA’s criteria mapping).
• A1.1: The entity maintains, monitors, and evaluates current processing capacity and use of system
components (infrastructure, data, and software) to manage capacity demand and to enable the
implementation of additional capacity to help meet its objectives.
• A1.2: The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and
monitors environmental protections, software, data backup processes, and recovery infrastructure to meet
its objectives.
• A1.3: The entity tests recovery plan procedures supporting system recovery to meet its objectives.
To identify what testing will be included with the addition of the availability trust services criteria, the
service auditor will walk through the services provided to your clients and identify control points in
the process. This could include controls such as (these are just a few examples taken from the AICPA’s
illustrative mapping (Mapping of 2017 TSC to 2016 TSC)):
• Measures Current Usage—Measurement of use of system components is performed to establish a baseline for
capacity management and to refer to when evaluating the risk of lack of availability due to capacity constraints.
• Forecasts Capacity—A forecast and comparison of expected average and high use of system components to
system capacity and tolerances is performed. Considerations include capacity in the event there is a system
failure.
• Identifies Environmental Threats—Management identifies environmental threats as part of the risk assessment
that could impair the availability of the system. These could include threats resulting from weather, failure of
environmental control systems, electrical discharge, fire, and flood/water.
• Designs Detection Measures—Measures are implemented for detecting anomalies that could result from
environmental threat events.
• Implements and Maintains Environmental Protection Mechanisms— Environment protection mechanisms are
implemented by Management to prevent and mitigate against environmental events.

• Responds to Environmental Threat Events—Procedures have been developed and put in place for responding
to environmental threats and for evaluating the effectiveness of those policies and procedures on an ongoing
or periodic basis. This includes, but is not limited to, automatic mitigation systems (i.e., UPS and generator
back-up subsystem).
• Implements Business Continuity Plan Testing—Business continuity plan testing is performed on at least an
annual basis. The testing includes (1) developing testing scenarios based on threat likelihood and magnitude;
(2) consideration of system components from the entire entity that can impact availability; (3) scenarios that
consider the potential for lack of availability of key personnel; and (4) updating continuity plans and systems
based on test results.
• Tests Integrity and Completeness of Back-Up Data—The integrity and completeness of back-up information is
tested on at least an annual basis.
Summary
While the availability TSC is not required in a SOC 2 examination, it is an important TSC for many service
organizations to demonstrate availability.

The 10 Generally Accepted Privacy Principles
Local, national, and international entities have established laws, regulations, and guidelines to protect
individual’s privacy. Privacy is considered being free from the observation and disturbance of others.
The International Association of Privacy Professionals (IAPP) specifies further that individuals have a
right to information privacy—the ability to control how one’s personal information is collected and used.
Organizations must be proactive in addressing the challenges of establishing and maintaining privacy
programs to safeguard personal information within their possession.
Why do we Need Privacy Protections?

We live in the Information Age, a time that truly epitomizes Sir Francis Bacon’s catchphrase that “knowledge
is power.” With a global economy driven by a digital industry that impacts nearly every aspect of our lives,
businesses are constantly collecting, storing, using, and sharing consumer data and information.
Technological innovation and the power of data analytics create remarkable value, but also present new
challenges. Threats to the security and privacy of personal information continue to grow as the value of
information has increased. The protection of personal information is appropriately of utmost importance to
many individuals and organizations around the world. Governing bodies at nearly every level have attempted
to legislate and regulate activities to protect their citizenry. The Health Insurance Portability and Accountability
Act (HIPAA) and the European Union’s General Data Protection Regulation are a couple of examples. Business
expend a great deal of resources complying with these regulations and protecting their data.

Yet, cyber-attacks and data breaches are constantly making headlines. In 2017, we learned that Equifax’s
database was breached through a vulnerability on its website, potentially exposing the personal information
(e.g., social security numbers, credit card numbers, driver’s license numbers, birth date, etc.) of an estimated
143 million people in North America and the United Kingdom. Even less assuring is the fact that the intrusion
took place between mid-May and July of that year, and the public announcement came nearly two months
after the company became aware of it. Unfortunately, this isn’t an isolated incident. The following are some
of the data breaches reported just this year:
• E-Sports Entertainment Association (ESEA) – 1.5 million records

• Xbox 360 ISO – 1.3 million users
• PSP ISO – 1.3 million users
• InterContinental Hotels Group (IHG) – 1,200 properties
• Arby’s – 1,000 restaurants
• River City Media – 393 million records
• Dun & Bradstreet – 33 million corporate contacts
• America’s JobLink – 4.8 million users
• Internal Revenue Service (IRS) – 100,000 taxpayers
• Gmail – 1 million users
• Verizon – 14 million subscribers
Experiencing such an event can be devastating to a business. Damage to the organization’s reputation and brand
are significant, as are potential legal reparations. Evidenced by Blue Cross and Blue Shield / Anthem’s announced
settlement of $115 million earlier this year for a 2015 data breach impacting 80 million of its customers.
GAPP Privacy: What are the Generally Accepted Privacy Principles?

Recognizing the challenges that businesses face in addressing privacy risks, the American Institute of
Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) organized the
Privacy Task Force to create a comprehensive framework that organizations could use to effectively manage
their privacy risks. The Privacy Task Force considered international regulatory privacy requirements and
industry best practices to develop the privacy guidance. The framework developed by the Privacy Task Force
is called the Generally Accepted Privacy Principles (GAPP). The GAPP consists of ten privacy principles. The
privacy principles are listed and summarized below:

1. Management. The entity defines, documents, communicates, and assigns accountability for its privacy
policies and procedures.
2. Notice. The entity provides notice about its privacy policies and procedures and identifies the purposes
for which personal information is collected, used, retained, and disclosed.
3. Choice and consent. The entity describes the choices available to the individual and obtains implicit or
explicit consent with respect to the collection, use, and disclosure of personal information.
4. Collection. The entity collects personal information only for the purposes identified in the notice.
5. Use, retention, and disposal. The entity limits the use of personal information to the purposes identified in
the notice and for which the individual has provided implicit or explicit consent. The entity retains personal
information for only as long as necessary to fulfill the stated purposes or as required by law or regulations
and thereafter appropriately disposes of such information.
6. Access. The entity provides individuals with access to their personal information for review and update.
7. Disclosure to third parties. The entity discloses personal information to third parties only for the purposes
identified in the notice and with the implicit or explicit consent of the individual.
8. Security for privacy. The entity protects personal information against unauthorized access (both physical
and logical).
9. Quality. The entity maintains accurate, complete, and relevant personal information for the purposes
identified in the notice.
10. Monitoring and enforcement. The entity monitors compliance with its privacy policies and procedures
and has procedures to address privacy related complaints and disputes.
The implementation and consistent application of the GAPP privacy framework or privacy principles will
enable an organization to effectively manage the collection, use, retention, disclosure, and disposal of data
requiring privacy protections.
What Types of Information Require Privacy Protections?

Organizations have a responsibility to keep a variety of data collected secure and private. A few of the most
common types of data requiring protection are personally identifiable information (PII) and protected health
information (PHI).

PII is broadly defined as any information that can be used to identify, contact, or locate a specific person.
The National Institute of Standards and Technology further specifies that PII is “any information about an
individual maintained by an agency, including (1) any information that can be used to distinguish or trace an
individual’s identity, such as name, social security number, date and place of birth, mother’s maiden name, or
biometric records; and (2) any other information that is linked or linkable to an individual, such as medical,
educational, financial, and employment information.”
HIPAA defines PHI as data or documentation including the following 18 identifiers:
1. Names
2. Geographic identifiers (more specific than state)
3. Dates specific to an individual (other than year only)
4. Phone numbers
5. Email addresses
6. Fax numbers
7. Social Security numbers
8. Medical record numbers
9. Health insurance beneficiary numbers
10. Account numbers
11. Certificate/license numbers
12. Vehicle identifiers (e.g., license plate or vehicle numbers)
13. Device serial numbers
14. Web URLs
15. IP address numbers
16. Biometric identifiers (such as finger, retinal, and voice prints)
17. Full face images
18. Any other number, characteristic, or code unique to an individual
PHI that is created, received, stored, or transferred in an electronic form is often referred to as ePHI. The
same privacy protections needed for PHI are required for ePHI.
How can your Organization Apply GAPP or Generally Accepted

Privacy Principles?
Organizations can use GAPP to design and implement a privacy policy, create and manage an internal privacy
program, and monitor its performance. There are five key components to using the GAPP principles to
establish and manage a privacy program: strategize, diagnose, implement, sustain and manage, and auditing.
Strategically Design Your Privacy Program

Creating a strategy or vision for the organization’s long-term direction and prosperity helps define the
culture and helps shape how the it will interact with external entities, including its customers. This process
should also help develop an overall master plan based on its strategic direction. Having a clear strategy and
master plan should help clarify the objective and align the organization toward it. If privacy compliance is
a critical component to your organization’s success, your strategic plan should identify the long-term goals
and major obstacles for becoming compliant with relevant privacy laws and regulations.

With long-term goals established, the final step of strategizing is assigning resources to execute the plan.
The allocation of resources would include the identification and assignment of human, financial, and other
resources for the strategic plan.
Diagnose Your Organization’s Control Environment

The diagnosis or assessment phase is critical to designing an effective privacy program. During this stage,
the organization analyzes its environment to identify where weaknesses, vulnerabilities, and threats exist.
The entity should not only identify potential areas for privacy risk, but should also consider processes or
controls in place to address them in order to identify any gaps. An assessor may utilize the management
criteria within the GAPP guidance to evaluate the entity against its privacy goals and to determine to what
extent the business is achieving those goals. If an organization lacks the resources or skill-set, they may want
to bring in a third-party who can perform the assessment and provide clear, actionable recommendations for
the organization to address during implementation. Any gaps can and should be addressed in its plan.
Implement Your Privacy Program

Having diagnosed its environment, the organization can now create an action plan to mobilize based on
the diagnostic recommendations. Leadership may utilize the illustrative controls and procedures related to
the 10 privacy principles in the GAPP guidance to address gaps and recommendations related to its privacy
program determined during the diagnosis phase.
The implementation phase includes the design and documenting of a privacy program and action plan to
implement and manage it. The plan should clearly define privacy ownership, assign responsibility and tasks,
establish an implementation schedule including major milestones, and measures of success.
Sustain and Manage the Program

The sustaining and managing phase is essentially the monitoring of the execution of the action plan to
ensure that it is being performed appropriately and, if necessary, variances are identified in a timely manner
to initiate corrective action. Monitoring would include the policies, processes, and supporting technology
utilized to ensure compliance with privacy policies and the ability to exhibit due diligence.
Auditing to Improve and Ensure Compliance

There are two components to auditing—internal and external. Internal auditors can perform objective
assessments and provide consulting services designed to add value and improve an organization’s
operational efficiency. Their assessments can help the entity to accomplish its strategic objectives by
bringing a systematic, disciplined approach to evaluate and improve the effectiveness of risk management,
control, and governance processes. Some organizations that need to comply with HIPAA may use internal
auditors to perform a self-assessment

It is common for customers to request that their service providers’ have an independent auditor (or external
auditor) assess the organization’s control environment to obtain assurance that controls are in place to
provide the security and maintain the privacy of their data. Certified Public Accounting (CPA) firms can
perform attestation and assurance services to build trust and confidence for individuals, management,
customers, business partners, and other users. As a Certified Public Accounting firm, Linford & Company LLP
specializes in the performance of SOC 2 and HIPAA compliance audits to help provide that assurance that
service providers are appropriately applying GAPP.
Summary
Every organization faces a significant challenge in maintaining the security and privacy of personal
information within its custody. The GAPP presents a framework of generally accepted principles and
practices that an entity can employ to mitigate risk of not maintain the privacy of its information assets.

New Criteria for SOC 2 Reporting on Cyber & Information Incidents
Over the last year, the world saw a number of major security breaches in the news. Some notable ones
include the Equifax data breach, Uber data breach, WannaCry cyber attack, and the list goes on. While
each of these had its own unique security vulnerability that was exploited they all shared in at least one
commonality, they experienced a security incident (i.e. information security or cybersecurity) that would
have required reporting under the new SOC 2 Guidance. In this post, we will talk about information and
cyber security incidents, the change in incident reporting expectations, implementing the new guidance, and
disclosure requirements.
What are Security Incidents?

The definition of an incident can vary depending on your company and the multiple factors at play.
With that said, NIST defines an incident as “an occurrence that actually or potentially jeopardizes the
confidentiality, integrity, or availability of an information system or the information the system processes,
stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security
procedures, or acceptable use policies.”
Using the definition defined above we will dissect a few of the incidents identified above.

• Equifax Data Breach: During the Equifax data breach, about 145 million U.S. consumers and businesses had
their information hacked as a result of a known vulnerability that existed on their web portal that was not
patched in a timely manner. Because of this breach, the confidentiality of consumer data was jeopardized,
making this an incident.
• Uber Data Breach: During the Uber data breach, hackers accessed a server which stored personally
identified information (PII) by gaining access to their code repository which contained login information
needed to gain access to Uber’s production environment. Like the Equifax data breach, the confidentiality of
Uber’s client information was jeopardized, making this an incident.
• WannaCry Cyber Attack: The WannaCry attack was a particular notable attack as it used a logic known
as worm tactics which allowed it to hop to other users through LAN and WAN connections. This allowed
the attack to disrupt entire networks for some that were infected. It spread through a known exploit within
an old file sharing protocol found in Windows systems released for over 15 years. During this attack, the
integrity and availability of the system were affected, making this an incident.
Old vs. New SOC 2 Incident Reporting Expectations

Up until the latest version of the SOC 2 guidance, which officially went into effect December 15, 2018, service
organizations receiving SOC 2 reports were not required to disclose major information security or cyber
security incidents that occurred either as of the date of the system description or during the audit period the
report covers. The only time it would have been mentioned is if the incident was the result of a control failure
due to poor design or if the control did not operate effectively.
According to the new guidance, management is now required to include specific information about incidents
that (1) occurred as a result of a failure in the design or operating effectiveness of one or multiple controls
or (2) upon occurrence resulted in the company not being able to meet service commitments and system
requirements.

According the AICPA, reportable security incidents should include the following information:
• Nature or description of the incident
• Timing around when the incident occurred
• The consequence the incident will have on the service organization, service organization’s users and any
disruption to service commitments and system requirements.
How to Implement the New Guidance?

The AICPA has an Assurance Services Executive Committee which works on different tasks that are designed
to offer guidance, criteria, and tools to support members of the AICPA in implementing requirements
published by the AICPA. This includes the Description Criteria for a Description of a Service Organization’s
System in a SOC 2 Report. Within this publicly available document is guidance around implementing the new
requirement of adding incidents to the system description.
Something important to note is that the AICPA understand that not all incidents are major and require
reporting to their users. The new Description Criteria provides considerations that management can use
when determining whether an information security or cyber security incident response is warranted, and
therefore meet the reporting requirements noted in the section above. The considerations are as follows:
Incident Response Considerations:

1. Was the incident a result from controls that were either not designed properly or did not operate
as intended?
2. As a result of the incident, was the service organization not able to meet the service commitment
and system requirements guaranteed to their users?
3. Are there any laws or regulations which will force the incident to be publicly disclosed, if it has not
been already?
4. Has or will the incident impact the financial stability or long-term operations of the service organization
and will this require a financial statement disclosure?
5. Did the incident require any type of legal or regulatory sanction?
6. Has or will the incident cause the service organization to cancel any major contracts?
If the answer to any of these considerations is yes, then it is likely that the incident needs to be reported
within the upcoming SOC 2 report.
I Have a Reportable Security Incident, What Now?
If by going through the considerations in the previous section and through conversations with the
appropriate personnel it is decided that an incident does need to be reported, it is important to understand
what that should look like.
When a company reports an incident, the information reported should be presented in a high-level for a
number of reasons. The first reason is that certain details could provide parties with bad intentions enough
information needed to further exploit the system. Secondly, the reporting of incidents is only intended to
provide readers with the description of the incident, timing, and any consequences the incident has caused.
Service organizations that determine they have a reportable incident should work with appropriate
personnel such as their auditor and legal team to ensure that the information provided will not result in
further damage to their system.
Preventing & Handling Cyber/Information Security Incidents

While our hope is that hacking and cyber security incidents do not continue to occur, the reality is that the
threat is out there and only seems to be growing. The best way to ensure that your service organization
lowers the risk of having to report on a security incident is by having a security management team with a
policy and plan that continues to identify, analyze, and remediate risks that can negatively impact users
and the system. But in the case that a security incident does occur, it is also important to understand the
requirements of disclosure as a means to avoid unnecessary exposure.

SOC 1 & 2: 7 Common Mistakes and How to Avoid Them
In performing SOC audits for Linford&Co, the clear majority of organizations do a great job providing
reasonable assurance they are meeting all their controls. But we wanted to hit on a list of seven common
mistakes that seem to pop up to hopefully help your organization identify them before they become an
issue. All the common mistakes below may qualify a report, create exceptions and/or create a less secure
environment, leaving your organization susceptible to external attacks. The list is not exhaustive, it is just a
sample of common mistakes and recommendations. Each environment is different and what works for one
organization may not work for others.
No or Lack of Organizational Buy-In

Lack of buy-in is an issue for every organization and is not specific to those undergoing a SOC 1 and/or SOC
2 audit. Many times, it can just be a nuisance that may impact performance, but when it comes to security
compliance, it can be particularly bad. If an organization does not follow the defined policies and processes, it
can lead to a less secure system, qualified report or even a breach. A single person not following the process
could cause major damage. For example, if employees are not allowed to download software from the internet
but one rogue admin downloads malware and installs it on a server, the organization’s security could be
compromised.
Educating staff about the purpose and benefits of policies and getting their commitment to comply are
essential for obtaining and maintaining compliance.

Inaccurate Access Controls and Permissions
Access control is an important topic and there are books written on how to implement. In this instance, I
want to focus on off-boarding and making sure to remove a user’s access when it is no longer needed. When
a staff member changes their job function or leaves the company, it is essential to ensure that their access
to the system is reviewed and updated accordingly, otherwise they may end up retaining privileged access
when they should not. This sounds like a simple task, but when you add in that an organization may have
many different applications, disconnected systems, last second changes, high priority issues, etc. a mistake is
bound to happen.
There are many ways to avoid this mistake, and below are just a few of them. Simply being aware of this gets
you much closer to defining a way to protect against it.
• Document which products have access controls and the roles/permissions that are defined in each. When a
user changes positions or leaves the company, having a detailed and accurate list will help ensure that their
permissions are updated/removed appropriately.
• Review roles and permissions on a regular basis. This will help one identify if a user was not removed or a
permission change was missed.
• Document changes to a user’s permissions in a service ticket or checklist and retain this information. This
provides historical evidence of the actions taken.
Poor or Nonexistent Inventory Management

Accurate inventory management is fundamental to maintaining a secure system and being able to
successfully obtain and maintain compliance. If an organization does not know what is on their network,
how are they supposed to ensure everything is patched and monitored? Rogue machines happen all the
time, most frequently because lifecycle management breaks down and a machine that is supposed to be
decommissioned continues to chug along, or with Bring Your Own Device (BYOD), devices are coming on
and off the network all the time. A single rogue device can be the downfall of even the most secure system.
Maintaining an accurate inventory of assets requires both technical and manual processes and procedures,
but the key to success is being diligent and monitoring frequently. Find a process and product/tool that
works for your organization. An organization can spend millions implementing a commercial product, but if
they never maintain it, all that money and time is for nothing.

Knowing what you have is only one part of inventory management, identifying what is not known or not
approved is where it can get tricky. To help find these unknown devices, organizations can do periodic
sweeps of the network, pull information from network devices, implement Mobile Device Manager (MDM)
products, log wireless devices, etc.
Unknown External Communications

Knowing and understanding the organization’s external communications is key to securing the system and
obtaining and maintaining compliance. External communications interface with vendors, third-party tools,
etc. and are usually the primary methods of contact with the organization’s customer base. Having insecure
or unknown external communications greatly increases an organization’s chance of a breach.
In 2015, the POODLE attack made SSLv3 obsolete and insecure. It is recommended organization’s disable
this protocol, but according to the 2016 TLS Telemetry Report provided by F5 Labs, as of October 2016, 23%
of the internet at large still is supporting it. Without an external vulnerability scan or well documented and
reviewed interface documents, organizations may still be using an insecure protocol and not even know it.
Performing external vulnerability scans and/or penetration tests is a great way to determine the security of
your external connections and network configuration. We also like to recommend that every organization
document their connections and review the connection details periodically.
Note: We recommend contacting your vendors for details on how to disable SSLv3. http://disablessl3.com/
is also a good resource to help your organization identify and disable the protocol.
No Separation of Duties
Separation of duty means that in order to complete a task, more than one person is required. When talking
about systems, this is especially important when it comes to Change Management. In Change Management,
you do not want to allow the same person to build, test and push updates to production. If only one person
can do everything, it creates an environment where a coding mistake could be pushed into production, or
more nefarious acts like installing a backdoor into the system, can be done without anyone knowing.

In larger organizations, separation of duties is overcome by adding more resources, but it becomes a bit
more difficult in a smaller organization where there are few resources with the skill set to know if the code is
written correctly, which may introduce a security risk to the system. The key to implementing separation of
duties is to ensure the resources are knowledgeable with regards to their job function and that changes to
the system require at least two people to implement. Also, removing developer access to push updates into
production and forcing a review will limit the risks with regard to Change Management.
Not Monitoring Subservice Organizations

In a related blog post, Newel Linford stated: “Subservice organizations perform at least some function
of the service organizations’ outsourcing activities. If the subservices perform functions that are relevant
to the user organizations, then the user organization needs to verify that the subservice is fulfilling their
obligations.” Many times, the user organizations don’t review if the subservice organization is meeting their
controls, which may lead to a control not being covered at all.
A user organization should be reviewing and monitoring their subservice organizations to ensure that they
are fulfilling their obligations as well as understanding what role the user organization should be fulfilling.
Poor Scoping of the Report

One of the first steps of obtaining a SOC report is to define the scope. If an organization specializes in
a certain service it can be simple and straightforward, but what if the organization offers many different
services? If an organization does not properly cover all the risks related to the services provided, they could
end up being deficient in certain areas, or on the flip side, it may end up costing the company quite a bit of
time and resources to enhance or add controls that are not required.
Understanding the service’s scope and boundaries starts with understanding the people, processes and
technology that support the service. From there, determine which risks are related to the service(s)
provided, generally through a risk matrix, and ensure that each risk is being addressed. If an organization
has not been directly told which type of report is required by their customer or auditor, then the
organization would also need to identify which report type is necessary. SOC 1 reports are for internal
controls over financial reporting, and a SOC 2 report includes security, confidentiality, processing integrity,
availability and privacy. For additional information on what report you may need, see: Need A SOC Report?
How To Know Which One Is Best For Your Service Organization.
Summary
Whether you are preparing for your first SOC audit or have been through an audit before, the above
common mistakes can sneak up on any organization and each one could qualify a report, create exceptions,
and/or create a less secure environment. Stay diligent, know your environment and monitor changes. With
proper processes and team buy-in, your SOC audit can be smooth and free of issues.

Who Can Perform a SOC Audit?
As the requirement to receive SOC 1 or SOC 2 reports as part of a contract, request for proposal (RFP),
or security program increases as a barrier to receiving major clients, it’s important to understand who can
perform these audits. This post will identify a number of questions to answer who exactly can perform
SOC 1 and SOC 2 audits.
Can a Non-CPA Organization Perform a SOC 1 & SOC 2 Audit?

No. If a firm is not a certified CPA firm, then they cannot complete a SOC 1 or SOC 2 audit that will be
acceptable in the eyes of the AICPA and users of the report cannot rely on the contents provided within.
A SOC 1 and SOC 2 examination has at least four main sections that users of the report should look for.
Those include the following:
• Management’s Assertion
• Auditor’s Opinion
• Description of Services
• Results of Testing
If a firm completes a SOC audit that is not a certified CPA firm, then they cannot provide an opinion of the
contents detailed within the Description or Services and Results of Testing. Because of this, it is imperative
to confirm that the firm your organization chooses to perform the SOC audit, meets this fundamental
requirement.

Can Non-CPA Organizations Partner with CPA firms to Perform
SOC 1 & SOC 2 Audits?
No. If you think otherwise, contact any member of the AICPA Trust Information Task Force. Any one of them
would be more than happy to take down your information and have a dialogue with you about this topic.
With that said, the AICPA requires that team members that work on engagements have a certain level of
competence and capabilities. While a non-CPA organization may have the technical capability to perform a
review of the services or system being examined, they must also have experience with the following:
• Evaluating the design of controls and the operating effectiveness to confirm that they have functioned
over a period of time and meet the applicable trust service criteria included in the report.
• Understand professional standards that are required by the AICPA such as the AICPA Code of Conduct along
with other audit standards that allow auditors to apply professional skepticism and judgment as required.
This, however, does not mean an auditor cannot enlist the use of a specialist, if required, to complete an audit.
This question will be addressed in question number five.
Are There Any Times a CPA Organization Cannot Perform

a SOC 1 and SOC 2 Audit?
Yes. As part of the AICPA Code of Conduct, CPA firms MUST be independent before they can engage with a
client to perform an audit. The AICPA requires that “a member in the public practice should be independent
in fact and appearance when providing auditing and other attestation services,” such as a SOC 1 or SOC 2
examination.
What are the Ramifications to the Service Organization if One of the Above
has Happened?
Any user organization and/or user auditor that relied on the SOC 1 or SOC 2 examination report from the service
organization may have placed unwarranted reliance on that SOC report. In other words, the user organization’s
financial statement audit may have to be performed again for each period in which there was unwarranted
reliance. Moreover, it is illegal to depart from state laws in regard to performing attestation services.

SOC 1 and SOC 2 follow the guidance found within the Statement on Standards for Attestation Engagement
(SSAE 18). SSAE 18 is meant to be a clarification and recodification which replaces SSAE 16 as the standard
for SOC 1 reports. SSAE 18 has integrated concepts found in AT-C section 105, Concepts Common to
All Attestation Engagements; AT-C section 205, Examination Engagements; AT-C section 210, Review
Engagements; and AT-C section 215, Agreed Upon Procedures. These standards together are now the
standards for both SOC 1 and SOC 2 reports. For more information on SSAE 18, check out other posts linked
within the summary section.
Guidance also exists that states that the only type of organization that may perform a SOC 1 and SOC 2
audits is a licensed CPA firm. The following bullets are selected excerpts from authoritative sources listing
some, but not all, of the relevant guidance supporting the comments above:
• “[A]uditor should not assume responsibility for the predecessor auditor’s work or issue a report that
reflects divided responsibility” (AICPA, AU315.16).
• “The independent auditor also has a responsibility to his profession, the responsibility to comply with the
standards accepted by his fellow practitioners” (AICPA, AU110.10). This includes adherence to CPE, Ethics,
and licensing requirements.
• “No person, partnership, professional corporation, or limited liability company shall, without an active
certificate of certified public accountant or a valid registration: Attest or express an opinion, as an
independent auditor” (Colorado Revised Statute 12-2-120 Unlawful Acts (6)(II)(B)).
• “The practitioner must adequately plan the work and must properly supervise any assistants” (AICPA,
AT101.42).
• “Attest services may only be rendered through firms holding permits from the state” they are performing
attest services. (Uniform Accountancy Act, Section 7).

Can a Firm Use the Work of a Specialist to Perform
a SOC 1 or SOC 2 Examination?
Yes. When engaging to perform a SOC 1 or SOC 2 examination, the auditor may decide it is necessary to
enlist the use of a specialist. AT-C 205, Examination Engagements requires that auditors assess the
following items:
• Does the specialist have the required skills to understand the service or system and do they have the
required independence to complete the required work?
• Is enough evidence available to the auditor to determine whether the specialist has the necessary
proficiency to understand the nature of the specialist’s work along with the scope of their expertise, and
determine whether the objective of their work meets the needs of their expected role as a specialist?
• Will the auditor and the specialist be able to come to an agreement on the expected work (i.e. nature,
scope, and objectives) to be completed by the specialist, the roles and responsibilities that will be
required of the specialist, when and the extent of work expected by the specialist, and the duties and any
confidentiality requirements that are expected of the specialist.
Through consideration and documentation of the items listed above, an auditor can engage the use
of a specialist.
Summary
The overall goal of an attestation engagement is to provide users of the report or clients of subservice
organizations, in this case, with an opinion on the assertions made by management. As a result, report users
can place reliance on the information before deciding whether they want to put an agreement or contract in
place to use that system or service. Because reliance is placed on these reports to enter into or agreement
often times, it is important to understand who exactly can perform a SOC 1 and SOC 2 audit.
The main take-away from this post is this: if the report is not completed by a CPA firm, the report should
not be relied on.

Get a SOC 1 Audit Get a SOC 2 Audit
https://linfordco.com

Soc 1 & 2 Audits Explained

Uploaded by

Copyright:

Available Formats

You might also like

Soc 1 & 2 Audits Explained

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Soc 1 & 2 Audits Explained

Uploaded by

Copyright:

Available Formats

REQUIRED READING FOR

Types of Controls Understanding an Audit Letter

How do Control Objectives Relate to Controls?

What are Audit Exceptions? A Definition

Complementary User Entity Controls, What is a SOC 1 Report? Expert Advice

Common Questions on SOC 1 (f. SSAE 16)

New Criteria for SOC 2 Reporting

Who Needs a SOC 2 Report? SOC 1 & 2: 7 Common Mistakes

Who Can Perform a SOC Audit?

Points of Focus in a SOC 2

Get a SOC 1 Audit Get a SOC 2 Audit 1

When Do You Use the Different Audit Testing Procedures?

Get a SOC 1 Audit Get a SOC 2 Audit 2

1. perform other procedures such as inspection, observation, or re-performance in combination

Get a SOC 1 Audit Get a SOC 2 Audit 3

Get a SOC 1 Audit Get a SOC 2 Audit 4

What is An Internal Control?

Get a SOC 1 Audit Get a SOC 2 Audit 5

IT Dependent Manual Controls

Get a SOC 1 Audit Get a SOC 2 Audit 6

Get a SOC 1 Audit Get a SOC 2 Audit 7

Get a SOC 1 Audit Get a SOC 2 Audit 8

What is a Control Objective?

Get a SOC 1 Audit Get a SOC 2 Audit 9

Get a SOC 1 Audit Get a SOC 2 Audit 10

Example Control Objectives and Controls

Get a SOC 1 Audit Get a SOC 2 Audit 11

Get a SOC 1 Audit Get a SOC 2 Audit 12

Integrated Audit Regulations: Who and When: The Requirements

Get a SOC 1 Audit Get a SOC 2 Audit 13

The Highlights: AS 2201

PCAOB Auditing Standard

Planning the Audit

Get a SOC 1 Audit Get a SOC 2 Audit 14

Controls Testing: Design vs. Operating Effectiveness

Using a SOC report in an Integrated Audit

SOC Integrated Audit

Get a SOC 1 Audit Get a SOC 2 Audit 15

Using a SOC Report

Get a SOC 1 Audit Get a SOC 2 Audit 16

What is a Subservice Organization?

Get a SOC 1 Audit Get a SOC 2 Audit 17

What are the Carve-Out Audit and Inclusive Auditing Methods?

Get a SOC 1 Audit Get a SOC 2 Audit 18

Get a SOC 1 Audit Get a SOC 2 Audit 19

Get a SOC 1 Audit Get a SOC 2 Audit 20

Get a SOC 1 Audit Get a SOC 2 Audit 21

Get a SOC 1 Audit Get a SOC 2 Audit 22

What are Complementary User Entity Controls?

More Examples of CUECs:

Get a SOC 1 Audit Get a SOC 2 Audit 23

Complementary vs. Compensating Controls

Get a SOC 1 Audit Get a SOC 2 Audit 24

Who has Responsibility for Complementary User Entity Control?

What are my Organization’s Complementary User Entity Controls?

Get a SOC 1 Audit Get a SOC 2 Audit 25

Get a SOC 1 Audit Get a SOC 2 Audit 26

Get a SOC 1 Audit Get a SOC 2 Audit 27