Do I need to disclose security incidents in my system description?

Under Description Criteria (DC) 4 of the description criteria for SOC 2, the AICPA requires disclosure of security incidents that affected the system, commitments, system requirements, or objectives. But we are often asked, “where is the line”? How do you know what needs to be disclosed versus what does not? This blog post will help to clarify that a bit when you are developing your system description for your SOC 2 report.

How does the AICPA define security incidents?

The AICPA defines security incidents as those that: (a) were the result of controls that were not suitably designed or operating effectively to achieve one or more of the commitments and system requirements; or (b) otherwise resulted in a significant failure in the achievement of one or more of those commitments and system requirements.

That’s a lot of dry language, but think about it this way, if the incident was the result of a control (or controls) not being designed or implemented properly, or if it didn’t operate properly, then it should be a security incident to be disclosed. For example, if a change wasn’t reviewed or approved prior to being pushed to production, and in turn left open a security vulnerability that was breached, that means you may have failed your security commitments for your system.

To disclose or not disclose?

If you have an incident that meets the terms above, you likely will need to disclose it. The AICPA does, however, provide additional guidance on determining whether to disclose an incident. In addition, to control failures, failure to meet commitments and system requirements (as above), the following should be considered when determining whether or not to disclose an incident:

  • Whether public disclosure of the incident was required (or is likely to be required) by cybersecurity laws or regulations

  • Whether the incident had a material effect on your company’s financial position or results of operations and required disclosure in a financial statement filing

  • Whether the incident resulted in sanctions by any legal or regulatory agency

  • Whether the incident resulted in your company’s withdrawal from material markets or cancellation of material contracts

Another rule of thumb that some companies use is if the incident warranted a press release, notice to your customers, or something similar, they will likely disclose it in their system description.

The AICPA also states that any incidents noted from your sub-service organization(s) should be considered for disclosure in your report as well.

How to disclose (what’s required)

OK, so you determined that you have a security incident that warrants disclosure. What now? Here is what you should include in your system description under DC 4:

  • What the incident was

  • When and how it happened

  • The extent of the incident (what got affected)

  • How did you stop it and remediate it?

  • Any changes in the control environment as a result

The AICPA also provides some leniency regarding disclosure. They state that disclosures about security incidents should not be made at a detailed level which might increase the likelihood that a hostile party could exploit a security vulnerability. Rather, the disclosures are intended to enable report users to understand the nature of the risks faced by your company and the impact of the realization of those risks.

Security incidents are a scary thing – we get it. Your job is to minimize the impact of those incidents. Always worry about that first.

When it comes to whether or not to disclose it in your SOC 2, we can help. Use this blog, the AICPA’s description criteria, the SOC 2 guide, as well as have a conversation with us to help you understand what needs to be disclosed around your incident.

SOC 2 Report Opinions

SOC 2 reports are attestation reports. With those types of reports, the Certified Public Accountant or CPA (i.e. service auditor) will have an opinion on management’s assertion as it relates to the system and its ability to meet commitments, system requirements, and objectives. This quick blog will show you the various types of report opinions that SOC 2 can result in and what each means.

Different Opinions

Unqualified Opinion

The first and most common SOC 2 report opinion is unqualified. Basically, that means it’s a “clean” opinion. No issues were noted in the description, controls, testing, etc. that would cause a modification of the opinion, and management’s assertion is deemed reasonable. This is the type of opinion you should be striving for. When you hear people refer to “passing” a SOC 2 examination, they are more than likely referring to an unqualified opinion.

The two main factors that drive the other opinions are scope limitations and material misstatements. A scope limitation is when your company is not able to provide evidence for the auditor. Material misstatements can happen due to a system description being misstated, controls not designed appropriately, or controls not operating effectively (exceptions or deviations in the testing of controls).

A control may have failed due to these exceptions, which in turn caused you to fail to meet criteria appropriately, or fail to meet commitments or system requirements (this is the most common cause of opinions other than unqualified). For example, a common control in a SOC 2 report is a requirement to perform risk assessments on at least an annual basis. If you did not perform a risk assessment within your testing period, this would be a control failure and would be denoted as an exception or deviation in your report.

Qualified Opinion

The next most common is a qualified opinion. This means that the report was mostly OK, but there was an issue somewhere. If there was a scope limitation and/or material misstatement, it might be material to the report (causing the qualification), but not pervasive enough to go any further. Should you panic if you have a qualified opinion? NO! Qualified opinions are more common than you think. Exceptions happen. It’s not the end of the world. Especially if it was one control that had an exception and everything else was fine. Many firms opt to explain their exceptions and why it was a rare occurrence or how they fixed it in an optional “unaudited” section of the report for management to respond to exceptions in testing (section 5 of the report).

Disclaimer of Opinion

Less common is the disclaimer of opinion, which mostly results from if there was a severe inability for your company to produce evidence for the examination (the scope limitation was material and pervasive).

Adverse Opinion

The least common is the adverse opinion. This rare report results from if there were material misstatements that were both material and pervasive to the point that the control environment is pretty much failing to meet either criteria, commitments, system requirements, or objectives.

Here is a graphic to help visualize how the opinions (other than unqualified) can happen:

SOC 2 Report Opinions

You should always strive for an unqualified opinion for your SOC 2. The first step in that is to make sure you have a solid control environment that is designed appropriately.

A Bytechek readiness assessment is a great way to get that started! Once suitability is determined to be OK (we recommend a type 1 report), just to make sure you operate your controls as described. If you do, you will reduce your likelihood of exceptions in testing, paving the way for your unqualified SOC 2 Type 2 report.

What is peer review?

When it comes to SOC 2 reporting, one of the most important aspects is something that you may never have seen or have considered when it comes to your CPA firm. Peer review. Peer review is what makes sure the CPA firm has its own policies and procedures in place to produce quality engagements that follow the rules for issuing SOC 2 reports. While CPA firms that don’t receive a “clean” peer review report can still practice, you should tread lightly.

What is peer review?

Peer review is a program that registered CPA firms are required to enroll in when they issue attestation or examination engagements (SOC 2). Once every 3 years, a CPA firm will be peer-reviewed by another CPA firm for its quality control (QC) system as well as the work they performed on specific engagements (selected by sampling). This is done in order to determine that the firm’s QC is adequate, they are complying with that system, and that the engagements are being performed in accordance with the applicable standards. During a peer review, the reviewing firm will ask questions, examine policies and procedures, and review engagement work papers in order to reach conclusions about the peer review.

When a CPA firm receives a report from the peer reviewer with a peer review rating of pass, the report means that the system is appropriately designed and being complied with by the CPA firm.

If a CPA firm receives a report with a peer review rating of pass with deficiencies, this means the system is designed and being complied with appropriately by the CPA firm in all material respects, except in certain situations that are explained in detail in the peer review report. When a firm receives a report with a peer review rating of fail, the peer reviewer has determined that the firm’s system is not suitably designed or being complied with, and the reasons why are explained in detail in the report.

Why is peer review important?

Peer review helps to monitor a CPA firm’s accounting and auditing practice (practice monitoring). The goal of the practice monitoring, and the program itself, is to promote and enhance quality in the services provided by the CPA firm. This goal serves the public interest and enhances audit quality for SOC 2 reports.

So now that you know about peer review, what do you do? It’s easy. You can request to see a CPA firm’s peer review report. Read it, and see what type of report they got (pass, pass with deficiencies, or fail), and then it’s up to you to decide.

Keep in mind that peer review happens once every 3 years for a CPA firm, and it takes a while for a peer review to be completed. So, if you see a peer review report from 2 years ago, it’s still current. Even one that is over 3 years ago might be current, as the CPA firm is currently undergoing their review and awaiting their new report.

Just talk to your CPA if the dates seem off.

What is an attestation report?

SOC 2 reports are, in official terms, attestation reports. So what does that mean and why is it relevant when thinking about SOC 2 reports?

First, the definition:

  • attestation report – a consulting service in which a CPA expresses a conclusion about the reliability of a written statement that is the responsibility of someone else

When we break down that definition, we can apply it to SOC 2 reports.

  • Consulting service – the examination engagement that the CPA will provide in order to deliver the SOC 2 report.

  • Expresses a conclusion – this is the actual CPA’s report, and often included as “section 1” of a complete SOC 2 report.

  • Written statement – this is “management’s assertion” in the SOC 2 report and often is included as “section 2”. The management assertion will state that the company prepared the system description, as well as that the controls in that description were suitably designed as of a specific date (and operating effectively over a period of time if a type 2 report).

Putting that all together, in our SOC 2 attestation report, we have:

  • Section 1 – CPA’s report with an opinion on management’s assertion

  • Section 2 – Management’s assertion that includes their statement about the system and its controls

  • Section 3 – System description

[1] “Attestation report – definition of attestation report by The Free ….” https://www.thefreedictionary.com/attestation+report. Accessed 10 Aug. 2020.

  • Section 4 – shows the criteria that the controls are measured against, the controls themselves, and in type 2, the CPAs testing of those controls and results of tests

So why is all of this relevant for SOC 2?

The boring answer is that attestations follow AICPA standards (in particular SSAE 18). But, when you break it down, it comes down to the assertion made by your company. In your assertion, you are going to state things like:

  • The system description was prepared in accordance with the AICPA’s description criteria

  • The system can meet the commitments to your customers (for security, availability, etc.), and that the system has requirements in place to help meet those commitments. (NOTE – these are measured against the in-scope trust services criteria).

Your CPA then comes in and measures these assertions through inquiry, examination, testing, etc. Your CPA then forms the report based on these tests, and from there, you have your SOC 2 report.

Who Can Issue SOC 2 Reports?

SOC 2 is an attestation report. Therefore, SOC 2 reports can only be issued by qualified CPAs. This is because they are putting their opinion on the report’s assertions, so the CPA has to understand not only the subject matter of SOC 2 but also how an attestation engagement needs to be performed. So how do you know if a CPA is qualified to issue SOC 2? See below.

Subject Matter Expert

The CPA firm (and specifically the CPA signing the SOC 2 report) should be knowledgeable on the subject matter of SOC 2 engagements. Make sure they understand IT controls, security, and other aspects that are relevant for your SOC 2 (cloud environments).

Look at any other credentials the CPA has or talk to them about their past experiences with SOC 2.

The Firm Is Licensed

The CPA firm needs to be licensed in its home state as well as have the ability to perform work in your state. Check out a CPA firm’s license in their home state’s board of accountancy website, and make sure the license is current.

The firm may also have “mobility” to perform in other states as well.

Peer Review

Peer review is the CPA profession’s way of “policing” itself. Another firm will come to review the CPA firm’s processes and procedures, as well as evaluate a sample of engagements from the firm in order to determine that the CPA firm is performing engagements the way they should meet industry requirements. You should ask for a copy of their peer review report and make sure that it is current. Similar to SOC 2, peer review reports are “clean” if unqualified.

The CPA firm should be peer-reviewed through either their state board of accountancy or the AICPA.

What’s in a System Description (SOC 2 – Section 3)

When thinking of SOC 2 reports, most people think about the auditor’s opinion and the controls (in section 4). But there is another vitally important section of a SOC 2 report, and that is the System Description (section 3). The reason this is so important is that, ultimately, it is what your SOC 2 report opinion is on. Wait, what? The opinion isn’t just about controls you say? That is absolutely the case and the system description is probably the biggest reason why it’s vital for your SOC 2.

This blog post is going to let you know more about the SOC 2 system description, what it is, what needs to be included in it, and some tips on how to make it easier when developing your SOC 2 report.

What is the System Description and why is it important?

The system description is exactly what it says. It’s a description of the system that is being reported on in your SOC 2 report. It is important because it gives your report users an overall understanding of your service and the system that is supporting it.

In your management assertion, the very first statement is “we have prepared the accompanying description of XYZ’s __ system…”. That statement goes on to have language about the description being presented in accordance with the AICPA’s description criteria (DC 200) and what the purpose of the description is (to inform report users about useful information related to assessing the risk of using your system – including the controls). There is also an explicit statement that the controls stated in the description were suitability designed (and operating effectively – type 2) in order to achieve commitments and system requirements based on the applicable trust services criteria. So really, the controls are already in the description. Section 4 of the SOC 2 report is a means of displaying those controls, how they map to criteria, and (in type 2) the auditor’s tests of controls and results of tests.

That in turn means that the CPA’s opinion, because it is essentially an opinion on the reasonableness of management’s assertion, is really about the system description in addition to the testing of those controls for suitability and operational effectiveness. That’s why the system description is so important. A poorly written description will not meet the requirements and therefore delay your SOC 2, or worse yet, result in a qualified opinion.

OK, so what’s in the system description?

The AICPA has provided a benchmark of 9 criteria for system descriptions of SOC 2 reports. They are as follows:

  1. Types of services provided – this is pretty straightforward. Here you will describe what services your company provides as it relates to the system in scope. There are a couple of key things to remember for this criterion. Some companies opt to describe their entire business in general, which is acceptable, but really this criterion should mostly focus on the system under examination. Another common theme we have seen in the past is companies using their marketing language in this section to describe the system (think “XYZ corp, a world-leader in ________” or “providing the best service in the industry” and even “______ system saves customers money by…”. Think about what we discussed above. Management’s assertion is about this description, and then the CPA’s opinion is about the reasonableness of the assertion. These types of statements are not measurable and are really just “sales” language. Stick to the facts of what the system is and does.

  2. Principal service commitments and system requirements – as we discussed in another blog, commitments and system requirements are crucial for the entire SOC 2 report. This section lets the reader know what those commitments and system requirements are, and where they come from (SLAs, contracts, etc.). This helps give the reader context as to what trust services categories are in-scope and why.

  3. Components of the system – This is where the description begins to get a little technical. The components described here include the infrastructure, software, people, procedures, and data that support and make up the system. For many Cloud Service Providers (CSP), the infrastructure section will include their hosting provider (such as Amazon Web Services). The software section should list your software and applications that support service delivery1. The people section should include a high-level overview of the departments or key personnel that support the system and what they do. Procedures should also be high-level, stating what procedures are and their purpose, but we recommend leaving the details of controls for later in the description. Data should discuss what the data is that the system processes (what is your customer data), as well as any other data that directly supports the system.

  4. System incidents – this part of the description should discuss any security incidents that rose to the level where your company failed to either meet criteria, your commitments to customers, or your system requirements. We go into much greater detail about system incident disclosures on the Bytechek blog.

  5. Applicable trust services criteria and related controls – this is probably the most “bulky” criterion of the system description. In this section, you will state the criteria that are in-scope so that the reader understands the criteria you are being measured against. That part is pretty standard. After that though, is where it gets super detailed. This is where you are going to discuss your control environment and describe the controls that support it. Things like logical access, change management, risk assessment and mitigation, communication, and other information are all included here, and essentially, this is where your auditor would find and pull your controls from that get tested in section 4. We recommend that you lay this section out similar to how the criteria are set up in section 4, which makes it easy for your report users to be able to understand your control environment as it relates to the criteria. Start with the control environment, information, and communication, risk assessment, etc. See the link above to read in more detail about the criteria to help you develop this part of your system description.

  6. Complementary user entity controls (CUECs) – a very important part of the description, CUECs are the controls that your customers need to have in place in order for the system and control environment to be complete and achieve its objectives. For example, maybe your customers need to have their own logical access controls in place so that only authorized users access your service, otherwise, unauthorized access may cause you to fail to meet your security commitments. The important thing to remember with this section is that it should not be a “laundry list” of things that you want customers to do in order for you to be covered in case something happens. That is what your contracts and agreements are for. This is purely just meant for controls they need to have in place otherwise your system doesn’t work to meet its objectives.

  7. Complementary subservice organization controls (CSOCs) – this criterion is where you will discuss the subservice organizations that support your system and control environment. Subservice organizations are a bit more involved than your vendors (or sometimes even critical vendors). Think of subservice organizations as a vendor that you cannot meet your criteria, commitments, or system requirements without. For most CSPs, that is going to be your cloud hosting provider (AWS, GCP, Azure, etc.). For example, you cannot meet the physical controls in CC6.4 or CC6.5 without them. So, you would list them here and what criteria they help you meet. Because you are only describing them in the system description, but not testing any of those controls (AWS isn’t letting you visit their DCs), most subservice organizations are “carved out” of the opinion in a SOC 2 report.

  8. Specific trust services criteria not applicable to the system – this is where you would describe any criterion that is not applicable to your system and why. An example could be where you have privacy in scope for your SOC 2, but you are not a data controller. Therefore things like the notice, choice, and consent criteria in privacy would be not applicable.

  9. Significant changes to the system during the period (Type 2 reports only) – in a type 2 report, if you had any significant changes (how the control environment operates, control changes in how they meet criteria, key personnel changes, mergers/acquisitions, etc.) during the period, you would state those here and their effect on the report.

That’s it!

System descriptions contain a lot of information, but important information for your users. That information has repercussions throughout the whole report, so making sure your description is well-done and accurate is crucial for your audit.

At ByteChek, we understand that writing a system description can be a daunting task, but we can help. Our platform includes a system description generator that helps you build and manage your system description.

What is SOC 2?

For many service organizations, the ability to show that their systems are secure is essential, if not required through their supply chain, contracts, or regulations. There are a variety of ways (reports) that organizations can show compliance or their security posture. One of the most common is through a SOC 2 attestation report. In this article, we’ll define SOC 2, discuss what the purpose of it is, how it’s used in business today, and provide a few tips on how to get started on the path for a successful SOC 2 report.

What is SOC 2?

SOC 2 is a report on a service organization’s controls relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy. SOC 2 reports are intended to inform users of detailed information and assurance about the controls at the service organization. These reports are provided by qualified CPAs, who form an opinion about the service organization’s system and the control environment.

First and foremost, SOC 2 is a report, and therefore you should think of it as a reporting framework, rather than the common misconception of it as a compliance framework. Think about it this way, SOC 2 is a way for a service organization to show its customers (through a system description) how they meet certain criteria prescribed from the AICPA that are relevant to the in-scope categories (security, availability, etc.).

The auditor’s job is to verify the information in the description provided by the service organization, as well as identify the specific controls from the description that meet the criteria. In the case of a type 2 report (period of time), the auditor will also determine if those controls operate effectively during that period of time. More on the differences between report “types” in this post.

Let’s use the security category as an example. The system description will describe the service organization’s system in accordance with certain AICPA defined criteria. One of those criteria is the control environment of the organization, which, at a high level, will describe the security controls the organization has related to things like onboarding, risk management, system operations, change management, logical access, etc.

Those controls will then be shown in more detail in another section of the report (typically “section 4”) according to how they meet each of the criteria related to the security category (for example, logical access criteria will have all of the controls related to logical access under it). In the case of a type 2 report, section 4 will also include the auditor’s testing of those controls as well as the results of tests over a period of time.

Depending on if the controls are designed appropriately to meet the prescribed criteria, as well as (in type 2) if those controls operated effectively, the auditor then forms an opinion for the report on that design and operational effectiveness.

The report itself is provided by the service organization to its customers so that those customers can have comfort in knowing that the system and its controls are designed appropriately and operating as described.

Why is SOC 2 Important?

SOC 2 reports are becoming more prevalent in the market and more companies are asking for them in order to meet contractual obligations, supply chain management, due diligence, or other requirements. For the service organization, the report becomes not just a means to deliver on these obligations, but also a way of showcasing your security posture, as well as improving it through making sure your controls will operate properly.

Don’t just take our word for it. According to the AICPA:

“These reports can play an important role in:

  • Oversight of the organization

  • Vendor management programs

  • Internal corporate governance and risk management processes

  • Regulatory oversight”

And because SOC 2 is more of a reporting framework as opposed to a compliance framework, it allows for more flexibility in how you can report on how you meet criteria, whereas in other frameworks, you’re just showing yes or no when determining if you meet their requirements.

With the involvement of CPAs, SOC 2 has the element of trust, as CPAs are held to a high standard of quality and integrity in how they produce opinions and reports. You can be assured that a qualified, highly skilled CPA will not only make sure the appropriate person(s) are testing your environment but that the report itself is structured to meet all the AICPA requirements.

Real Examples of SOC 2

To see how SOC 2 is relevant for service organizations, look no further than the biggest cloud service providers. Microsoft, AWS, and Google Cloud all have SOC 2 for their offerings. The links below will bring you to their landing pages for their SOC 2 reports, but to obtain a copy, you will have to request it from your representative or through their respective sites.

https://docs.microsoft.com/en-us/microsoft-365/compliance/offering-soc?view=o365-worldwide

https://aws.amazon.com/compliance/soc-faqs/

https://cloud.google.com/security/compliance/soc-2

NOTE – SOC 2 is not limited to cloud service providers, but can be applied to many different types of organizations.

Tips and Reminders for SOC 2

  • Remember that SOC 2 is a reporting framework. As a service organization, you are showing (reporting) what you have in place to meet certain criteria, and a CPA is reporting on if what you have is adequate and operating effectively.

  • Always use a qualified, peer-reviewed CPA firm to assist with SOC 2 efforts. Determination of a CPA firm’s peer review can be done through their home state’s board of accountancy, or through the AICPA. Make sure they understand IT auditing and SOC 2!

  • Get to know the description criteria and (for your organization) relevant trust service category criteria as you are pursuing SOC 2. Understanding the criteria for both before you start will help with readiness assessments and overall development of your control environment.

This blog post was to provide you with a basic understanding of SOC 2. There is a lot more nuanced and detail that goes into determining what your SOC 2 path will be and what needs to be included (or excluded) from your report. Be sure to look at ByteChek’s other SOC resources to answer your other questions, boost your understanding of SOC 2, and help you determine what is going to make the most sense for your organization.

Key SOC 2 Terms

Applicable Trust Services Criteria:

The criteria codified in TSP section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, and TSP section 100A, Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, of AICPA Trust Services Criteria, used to evaluate controls relevant to the trust services category or categories included within the scope of a particular examination.

Architecture:

The design of the structure of a system, including logical components, and the logical interrelationships of a computer, its operating system, a network, or other elements.

Authentication:

The process of verifying the identity or other attributes claimed by or assumed of an entity (user, process, or device) or to verify the source and integrity of data.

Authorization:

The process of granting access privileges to a user, program, or process by a person who has the authority to grant such access.

Board or Board of Directors:

Individuals with responsibility for overseeing the strategic direction of the service organization and the obligations related to the accountability of the service organization. Depending on the nature of the service organization, such responsibilities may be held by a board of directors or supervisory board for a corporation, a board of trustees for a not-for-profit service organization, a board of governors or commissioners for a government service organization, general partners for a partnership, or an owner for a small business. boundaries of the system (or system boundaries). The boundaries of a system are the specific aspects of a service organization’s infrastructure, software, people, procedures, and data necessary to provide its services. When systems for multiple services share aspects, infrastructure, software, people, procedures, and data, the systems will overlap, but the boundaries of each system will differ. In a SOC 2® engagement that addresses the confidentiality and privacy criteria, the system boundaries cover, at a minimum, all the system components as they relate to the life cycle of the confidential and personal information within well-defined processes and informal ad hoc procedures.

Business Partner:

An individual or business (and its employees), other than a vendor, who has some degree of involvement with the service organization’s business dealings or agrees to cooperate, to any degree, with the service organization (for example, a computer manufacturer who works with another company who supplies it with parts).

Carve-Out Method:

Method of addressing the services provided by a sub-service organization in which the components of the sub-service organization’s system used to provide the services to the service organization are excluded from the description of the service organization’s system and from the scope of the examination. However, the description identifies (1) the nature of the
services performed by the sub-service organization; (2) the types of controls expected to be performed at the sub-service organization that is necessary, in combination with controls at the service organization, to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved; and (3) the controls at the service organization used to monitor the effectiveness of the sub-service organization’s controls.

Collection:

The process of obtaining personal information from the individual directly (for example, through the individual’s submission of an internet form or a registration form) or from another party such as a business partner.

Complementary Sub-Service Organization Controls:

Controls that service organization management assumed, in the design of the service organization’s system, would be implemented by the sub-service organization that is necessary, in combination with controls at the service organization, to provide reasonable assurance that the service organization’s service commitments and system requirements are achieved.

Complementary User Entity Controls:

Controls that service organization management assumed, in the design of the service organization’s system, would be implemented by user entities and are necessary, in combination with controls at the service organization, to provide reasonable assurance
that the service organization’s service commitments and system requirements would be achieved.

Component (of Internal Control):

One of five elements of internal control, including the control environment, risk assessment, control activities, information and communication, and monitoring activities.

Compromise:

This refers to a loss of confidentiality, integrity, or availability of information, including any resulting impairment of (1) processing integrity or availability of systems or (2) the integrity or availability of system inputs or outputs.

Consent:

This privacy requirement is one of the fair information practice objectives. Individuals must be able to prevent the collection of their personal data unless legally required. If an individual has a choice about us or disclosure of his or her information, consent is the individual’s way of giving permission for the use or disclosure. Consent may be affirmative (for example, opting in) or implied (for example, not opting out). There are two types of consent:

  • explicit consent. A requirement that an individual “signifies” his or her agreement with a data controller by some active communication between the parties.

  • implied consent. When consent may reasonably be inferred from the action or inaction of the individual.

Contractor

An individual, other than an employee, engaged to provide services to an entity in accordance with the terms of a contract.

Control Activity:

An action established through policies and procedures that help ensure that management’s directives to mitigate risks to the achievement of objectives are carried out.

Controls at a Service Organization:

The policies and procedures at a service organization that are part of the service organization’s system of internal control. Controls exist within each of the five COSO internal control components: control environment, risk assessment, control activities, information and communication, and monitoring. The objective of a service organization’s system of internal control is to provide reasonable assurance that its service commitments and system requirements are achieved.

Controls at a Sub-Service Organization:

The policies and procedures at a sub-service organization that are relevant to the service organization’s achievement of its service commitments and system requirements.

COSO:

The Committee of Sponsoring Organizations of the Treadway Commission. COSO is a joint initiative of five private sector organizations and is dedicated to providing thought leadership through the development of frameworks and guidance on enterprise risk management, internal control, and fraud deterrence. (See www.coso.org.)

Criteria:

The benchmarks used to measure or evaluate the subject matter.

Cybersecurity Objectives

The objectives that an entity establishes to address the cybersecurity risks that could otherwise threaten the achievement of the entity’s overall business objectives.

Cybersecurity Risk Management Examination

An examination engagement to report on whether (a) management’s description of the entity’s cybersecurity risk management program is presented in accordance with the description criteria and (b) the controls within that program were effective to achieve the entity’s cybersecurity objectives based on the control criteria. A cybersecurity risk management examination is performed in accordance with the attestation standards and the AICPA Guide Reporting on an Entity’s Cybersecurity Risk Management Program and Controls.

Cybersecurity Risk Management Examination Report

The end product of the cybersecurity risk management examination, which includes management’s description of the entity’s cybersecurity risk management program, management’s assertion, and the practitioner’s report.

Data Subjects

The individuals about whom personal information is collected.

Deficiency

A term used to identify misstatements resulting from controls that were not suitably designed or did not operate effectively

Description of Misstatement.

The term used to describe differences between (or omissions in) the description and the description criteria.

Design

As used in the COSO definition of internal control, the internal control system design is intended to provide reasonable assurance of the achievement of an entity’s objectives.

Deviation

A term used to identify misstatements resulting from the failure of controls to operate in a specific instance. A deviation may, individually or in combination with other deviations, result in a deficiency.

Disclosure (of Information)

The release, transfer, provision of access to, or divulging in any other manner of information outside the entity holding the information. Disclosure is often used interchangeably with the terms sharing and onward transfer.

Disposal

A phase of the data life cycle that pertains to how an entity removes or destroys data or information.

Entity

A legal entity or management operating model of any size established for a particular purpose. A legal entity may, for example, be a business enterprise a not-for-profit organization, a government body, or an academic institution. The management operating model may follow product or service lines, divisions, or operating units, with geographic markets providing for further subdivisions or aggregations of performance.

Entity-Wide

Activities that apply across the entity—most commonly in relation to entity-wide controls. environmental protection and safeguards. Controls and other activities implemented by the entity to detect, prevent, and manage the risk of casualty damage to the physical elements of the information system (for example, protection from fire, flood, wind, earthquake, power surge, or power outage).

External Users

Users, other than entity personnel, who are authorized by entity management, customers, or other authorized persons to interact with the entity’s information system.

Fraud

An intentional act involving the use of deception that results in a misstatement in the subject matter or the assertion.

Inclusive Method

Method of addressing the services provided by a sub-service organization in which the description of the service organization’s system includes a description of (a) the nature of the services provided by the sub-service organization and (b) the components of the sub-service organization’s system used to provide services to the service organization, including the sub-service organization’s controls that are necessary, in combination with controls at the service organization, to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved. (When using the inclusive method, controls at the sub-service organization are subject to the service auditor’s examination procedures. Because the sub-service organization’s system components are included in the description, those components are included in the scope of the examination.)

Information and Systems.

Refers to information in electronic form (electronic information) during its use, processing, transmission, and storage and systems that use, process, transmit or transfer, and store information.

Information Assets

Data and the associated software and infrastructure used to process, transmit, and store information.

Information Life Cycle

The collection, use, retention, disclosure, disposal, or anonymization of confidential or personal information within well-defined processes and informal ad hoc procedures.

Inherent Limitations

Those limitations of all internal control systems. The limitations relate to the preconditions of internal control, external events beyond the entity’s control, limits of human judgment, the reality that breakdowns can occur, and the possibility of management override and collusion.

Intended Users

Individuals or entities that the service organization intends will be report users.

Internal Control

A process, effected by a service organization’s board of directors, management, and other personnel, designed to provide reasonable assurance regarding the achievement of objectives relating to operations, reporting, and compliance.

Management’s Assertion

A written assertion by the management of a service organization or management of a sub-service organization, if applicable, about whether (a) the description of the system is in accordance with the description criteria, (b) the controls are suitably designed, and (c) ina type 2 report, the controls operated effectively to achieve the service organization’s service commitments and system requirements based on the applicable trust services criteria.

Management Override

Management’s overruling of prescribed policies or procedures for illegitimate purposes with the intent of personal gain or an enhanced presentation of an entity’s financial condition or compliance status.

Operating Effectiveness (or Controls That Are Operating Effectively).

Controls that operated effectively provide reasonable assurance of achieving the service organization’s service commitments and system requirements based on the applicable trust services criteria. personal information. Information that is about, or can be related to, an identifiable individual.

Policies

Management or board member statements of what should be done to effect control. Such statements may be documented, explicitly stated in communications, or implied through actions and decisions. Policies serve as the basis for procedures.

Privacy Notice

A written communication by entities that collect personal information to the individuals about whom personal information is collected that explains the entity’s (a) policies regarding the nature of the information that they will collect and how that information will be used, retained,
disclosed, and disposed of or anonymized and (b) commitment to adhere to those policies. A privacy notice also includes information about such matters as the purpose of collecting the information, the choices that individuals have related to their personal information, the security of such information, and how individuals can contact the entity with inquiries, complaints, and disputes related to their personal information. When a user entity collects personal information from individuals, it typically provides a privacy notice to those individuals.

Principal Service Commitments

Disclosures included in the description of the service organization’s system related to the service commitments made by management to its customers about the system used to provide the service. The principal service commitments are those that are relevant to meeting the common needs of the broad range of SOC 2® report users.

Report Users (Specified Users or Specified Parties) of a SOC 2 ® Report.

In this document, the term refers to users of a SOC 2® report. The service auditor’s report included in a SOC 2® report ordinarily includes an alert restricting the use of the report to specified parties who possess sufficient knowledge and understanding of the service organization and the system to understand the report. The expected knowledge is likely to include an
understanding of the following matters:

  • The nature of the service provided by the service organization

  • How the service organization’s system interacts with user entities, business partners, sub-service organizations, and other parties

  • Internal control and its limitations

  • Complementary user entity controls and complementary sub-service organization controls and how those controls interact with the controls at the service organization to achieve the service organization’s service commitments and system requirements

  • User entity responsibilities and how they may affect the user entity’s

  • ability to effectively use the service organization’s services

  • The applicable trust services criteria

  • The risks that may threaten the achievement of the service organization’s

  • service commitments and system requirements and how controls address those risks

Users likely to possess such knowledge include user entities and their personnel business partners and their personnel, practitioners providing services to such user entities and business partners, prospective user entities and business partners, and regulators who understand how the service organization’s system may be used to provide the services.

Responsibilities of External Users.

Those activities and tasks that service organization management expects user entities, their employees, and any other third-party users of the system to perform for the services provided by the service, organization to function as intended to meet the needs of user entities.

Retention

A phase of the data life cycle that pertains to how long an entity stores information for future use or reference. risk. The possibility that an event will occur and adversely affect the achievement
of objectives.

Responsibilities of External Users

The risk that the description of the service organization’s system that was implemented and operated is not presented in accordance with the description criteria or that controls were not suitably designed or operating effectively to provide reasonable assurance that
the service organization’s service commitments and system requirements would be achieved.

Security Event

An occurrence, arising from actual or attempted unauthorized access or use by internal or external parties, that impairs or could impair the availability, integrity, or confidentiality of information or systems, result in unauthorized disclosure or theft of information or other assets, or cause damage to systems.

Security Incident

A security event that requires actions on the part of an entity in order to protect information assets and resources.

Senior Management

The chief executive officer or equivalent organizational leader and senior management team.

Service Auditor

As used in this guide, a CPA who performs a SOC 2® examination of controls within a service organization’s system relevant to security, availability, processing integrity, confidentiality, or privacy.

Service Commitments

Declarations made by service organization management to user entities and others (such as user entities’ customers) about the system used to provide the service. Service commitments can be communicated in written individualized agreements, standardized contracts, service level agreements, or published statements (for example, in a security practices statement).

Service Organization

An organization, or segment of an organization, that provides services to user entities.

Service Provider

A vendor (such as a service organization) engaged to provide services to the entity.

Includes outsourced services providers as well as vendors that provide services not associated with business functions such as janitorial, legal, and audit services

SOC 2 ® Examination

An examination engagement to report on whether (a) the description of the service organization’s system is in accordance with the description criteria, (b) the controls were suitably designed to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved based on the applicable trust services criteria, and (c) in a type 2 report, the controls operated effectively to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved based on the
applicable trust services criteria. The SOC 2® examination is performed in accordance with the attestation standards and the AICPA Guide SOC 2® Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy.

SOC 3 Engagement

An examination engagement to report on management’s assertion about whether controls within the system were effective to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved based on the trust services
criteria relevant to one or more of the trust services categories (applicable trust services criteria). subsequent events. Events or transactions that occur after the specified period covered by the engagement, but prior to the date of the service auditor’s report, which could have a significant effect on the evaluation of the presentation of the description of the service organization’s system or the evaluation of the suitability of design and operating effectiveness of controls.

Sub-service Organization

A vendor used by a service organization that performs controls that are necessary, in combination with controls at the service organization, to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved.

Suitability of Design (or Suitably Designed Controls)

Controls are suitably designed if they have the potential to provide reasonable assurance that the service organization’s service commitments and system requirements would be achieved. Suitably designed controls are operated as designed by persons who have the necessary authority and competence to perform the control.

System

Refers to the infrastructure, software, procedures, and data that are designed, implemented, and operated by people to achieve one or more of the organization’s specific business objectives (for example, delivery of services or production of goods) in accordance with management-specified
requirements.

System Components

This refers to the individual elements of a system, which may be classified into the following five categories: infrastructure, software, people, procedures, and data.

System Event

An occurrence that could lead to the loss of, or disruption to, operations, services, or functions and result in a service organization’s failure to achieve its service commitments or system requirements. Such an occurrence may arise from actual or attempted unauthorized access or use
by internal or external parties and (a) impair (or potentially impair) the availability, integrity, or confidentiality of information or systems; (b) result in unauthorized disclosure or theft of information or other assets or the destruction or corruption of data; or (c) cause damage to systems. Such occurrences also may arise from the failure of the system to process data as designed or from the loss, corruption, or destruction of data used by the system.

System Incident

A system event that requires action on the part of service organization management to prevent or reduce the impact of the event on the service organization’s achievement of its service commitments and system requirements.

System Requirements

Specifications about how the system should function to (a) meet the service organization’s service commitments to user entities and others (such as user entities’ customers); (b) meet the service organization’s commitments to vendors and business partners; (c) comply with relevant laws and regulations and guidelines of industry groups, such as business or trade associations; and (d) achieve other objectives of the service organization that are relevant to the trust services categories addressed by the description. Requirements are often specified in the service organization’s system policies and procedures, system design documentation, contracts with customers, and government regulations.

Test of Controls

A procedure designed to obtain evidence about whether controls operated effectively to achieve the service organization’s service commitments and system requirements based on the applicable trust services criteria.

Third-Party

An individual or organization is other than the service organization and its employees. Third parties may be customers, vendors, business partners, or others.

Trust Services Criteria

A set of professional attestation and advisory services based on a core set of criteria (trust services criteria) related to security, availability, processing integrity, confidentiality, or privacy.

Unauthorized Access

Access to information or system components that (a) has not been approved by a person designated to do so by management and (b) compromises segregation of duties, confidentiality commitments, or otherwise increases risks to the information or system components beyond the levels approved by management (that is, access is inappropriate).

User Entity

An entity that uses the services provided by a service organization.
user or intended user. An individual or entity that the service auditor expects will use the service auditor’s report.

Vendor

An individual or business (and its employees) engaged to provide services to the service organization. Depending on the services a vendor provides (for example, if it operates certain controls on behalf of the service organization that is necessary, in combination with the service organization’s controls, to provide reasonable assurance that the service organization’s service commitments and system requirements were achieved), a vendor might also be a sub-service organization.

What does the AICPA do for SOC 2 reports?

The American Institute of Certified Public Accountants (AICPA) is a U.S. organization that serves the accounting profession and, in particular, CPAs. The AICPA governs a variety of standards and practices that are relevant for CPAs. Because SOC 2 reports are attestation reports, they fall under standards issued by the AICPA for both the service organization and service auditor (or CPA).

How does the AICPA get involved?

The AICPA has a variety of committees, task forces, working groups, etc. that help with the development of standards and practices. Many times, an executive committee will determine what standards and practices need to be developed, updated, etc. From there, working groups or task forces are formed to develop what is needed.

Those working groups consist of AICPA personnel, as well as CPAs in the profession that are knowledgeable of both the subject matter and professional standards. A LOT of work gets put into those groups, and a consensus is formed around the applicable subject matter. There is a technical review, then an executive committee review and approval. After that, there is more review, and standards are then put into place. This is how SSAE 18 was developed, which is the primary standard that drives SOC 2 engagements.

CPAs are also held to other general standards, such as their code of professional conduct, ethics, etc. The AICPA is also involved in the development of those standards as well.

In order for the AICPA to monitor CPA firms for compliance with these standards, there is a peer review process that CPAs have to go through for any attest engagements (including SOC 2). That process determines whether the CPA has followed all applicable standards and practices relative to SOC 2 engagements. CPAs that don’t follow those standards are subject to a variety of penalties.

The AICPA is constantly evolving along with the accounting profession. SOC 2 standards have changed over the years and will continue to change along with technology and other advancements. While there is nothing stated yet, we would expect to see further changes in SOC 2 standards as they relate to automation and new privacy standards and regulations.

What is the Difference Between SOC 2 Security & SOC 2 Confidentiality

For most companies preparing for SOC 2 examinations, deciding which Trust Services Categories (TSCs) should be in scope is a difficult and sometimes confusing decision. Two of the categories that present a little confusion are the security and confidentiality categories since these terms are used interchangeably in the information security industry. However, in a SOC 2 examination, the differences between these two categories are clear and should be understood before making a decision on which should be included in your SOC 2 report. In this post, we will describe the differences between Security and Confidentiality, and also explain a few key reasons why it is important to understand those differences.

What is the difference between Security and Confidentiality in a SOC 2 examination?

In a SOC 2 examination, the Trust Services Categories (TSC) assessed should be based on your organization’s commitments and system requirements. Most, if not all, SOC 2 examinations include the Security TSC, so think of Security as the default category for a SOC 2 examination. This category addresses common information security concepts such as risk assessment, logical access, monitoring, HR procedures, data encryption, and more. While some of these concepts address general confidentiality principles, the SOC 2 Confidentiality TSC specifically addresses how your organization maintains and disposes of confidential data.

Going back to your commitments, a major aspect of the Confidentiality TSC is focused on the commitments you make to your customers regarding the deletion or removal of their data when they leave your service. If you commit to your Master Services Agreement (MSA) to deleting all customer data within 30 days after they leave the service or only upon request, the Confidentiality TSC is probably right for your organization. Another main component is around the maintenance of your sensitive data which is often addressed through controls covered in the common criteria or Security TSC. There are additional concepts covered in the Confidentiality Trust Service Criteria but the most important one to think about when deciding whether to include Confidentiality in scope is based on the data maintenance and disposal commitments made to your customers.

Why is it Important to Understand the Difference?

If you’re pursuing a SOC 2 examination, your customers will expect to see the Security TSC. Adding additional TSCs shows an additional level of maturity and could differentiate your company from its competitors. It is important to understand what the Confidentiality TSC is communicating to your customers prior to including it in scope. If you do not make any commitments regarding the disposal of customer data when they leave your service or request deletion, then the Confidentiality TSC may not be suitable for your company.

Adding an additional TSC requires additional effort from both your team and your third-party auditing team. This additional level of effort results in increased auditor fees due to additional reporting requirements and unnecessary overhead at status quo compliance firms. This additional TSC also results in a few additional evidence requests, more on that in this overview of the Confidentiality Trust Service Criteria. While the additional evidence and level of effort are proportionately less than the Security TSC, you want to be sure of the applicability of each additional TSC (Availability, Confidentiality, Processing Integrity, or Privacy) prior to including them in your SOC 2 examination.

At Bytechek, it is important to us that your SOC 2 examination provides value to the readers of your report and does not include criteria that are not relevant or include a plethora of not applicable statements.

ByteChek's platform helps companies of all sizes establish security programs, automate cybersecurity readiness assessments, and complete cyber security assessments faster – all from a single platform.

With ByteChek, companies can quickly build their information security policy from the ground up utilizing the ByteChek information security policy generator. The ByteChek platform then connects with the applications companies use every day to eliminate evidence collection and vague auditor requests.