To determine if your company is trustworthy, prospects, customers, and investors will want to see some kind of proof. That’s where SOC 2 comes in. Your SOC 2 report will serve as a testament to your company’s commitment to security and data privacy practices.
To obtain a SOC 2 report and prove that your organization is adhering to security guidelines, a third-party compliance expert conducts an audit. A SOC 2 audit is an unbiased evaluation of how well your business creates security protocols and implements them.
What is a SOC 2 audit
A SOC 2 audit is the process of assessing the way an organization upholds security and compliance through policies, practices, and controls. There are two main reasons why companies go through SOC 2 audits.
1) Undergoing a SOC 2 audit helps businesses develop a deeper understanding of how secure (or not secure) their organization actually is. Protecting sensitive data should rank high on the list of priorities for any business.
2) Organizations undergo SOC 2 audits in order to receive a SOC 2 report, which provides detailed information about internal security practices and protocols. Once obtained, this report can be shared with anyone who requests to see proof of security such as regulators, vendors, and especially prospective customers.
SOC2 has 61 compliance requireemtns.
SOC2 Status Summary and Maturity Model
Status Summary
Our organization’s status toward achieving the five TSCs (Trust Services Criteria) for SOC2 developed by the AICPA Assurance Services Executive Committee (ASEC) is summarized in (this polar chart, with a line for each moment of time, starting from A to B to C at completion: SAMPLE:
Note:
Maturity Model Levels
|
Maturity
Rating Based on CMMI |
|
|
5 Optimizing |
|
|
4 Quantitatively
Manager |
|
|
3 Defined |
|
|
2 Managed |
|
|
1 Initial |
|
Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Administered by the CMMI Institute, a subsidiary of ISACA, it was developed at Carnegie Mellon University (CMU). It is required by many U.S. Government contracts, especially in software development. CMU claims CMMI can be used to guide process improvement across a project, division, or an entire organization.
CMMI defines the following five maturity levels (1 to 5) for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing.
SOC 2 Trust Services Criteria
SOC 2 reports contain detailed information about your organization’s adherence to five standard categories known as the Trust Services Criteria.
The difficult part of the SOC 2 process is knowing which requirements are important to your organization. Businesses have a lot of jurisdiction when it comes to designing their compliance environment. All SOC 2 reports include the Security category; the other categories are optional. AICPA’s Trust Services Criteria includes 33 main requirements and 28 optional requirements.
1. Security
The Security Trust Criteria is all about protecting information from unauthorized disclosure.The Security Criteria are also known as the Common Criteria. They prove that a service organization’s systems and control environment are protected against unauthorized access and other risks.
Security is the only Trust Services Criteria required for every SOC 2 audit. The other criteria can be added to your report scope if your organization chooses, but they are not required to achieve SOC 2 compliance.
2. Availability
The Availability Criteria determine whether your employees and clients can rely on your systems to do their work.Some examples are data backups, disaster recovery, and business continuity planning. Each of these minimizes downtime in the event of an outage. For instance, if your data center is flooded, you have multiple power and computing redundancies. This ensures that data is available even in the event of hardware failure.
Consider adding to your SOC 2 if:
- You offer a continuous delivery or deployment platform.
- An outage would prevent your clients from building or deploying changes to their services. (E.g., cloud computing or cloud data storage providers)
3. Processing Integrity
The Processing Integrity Criteria determine whether a system works properly. Does it perform its intended functions without delay, error, omission, or accidental manipulation?This isn’t the same as data integrity — a system can work properly with incorrect data. For example, say you’re an e-commerce company. If a customer can complete the process of placing an order, your company meets the Processing Integrity Criteria.
Now say the customer accidentally enters the wrong address. This is an example of poor data integrity. You may still meet the processing integrity requirement. Your system works the way it’s supposed to, delivering that item to the address specified. It just won’t arrive on the right customer’s doorstep.
Consider adding to your SOC 2 if:
- You provide financial reporting services, or you're an e-commerce company.
- You need to ensure your transaction processing is accurate to combat fraud.
4. Confidentiality
The Confidentiality Criteria evaluates how organizations protect confidential information. I.e., by limiting its access, storage, and use. It can help organizations define which individuals can access what data and how that data can be shared. This ensures that only authorized people can view sensitive information, like legal documents or intellectual property.Consider adding to your SOC 2 if:
- Your organization handles confidential information. Examples include financial reports, passwords, business strategies, and intellectual property.
5. Privacy
This TSC looks at how an organization's control activities protect customers’ personally identifiable information (PII). It also ensures that a system that uses personal data complies with the AICPA’s Generally Accepted Privacy Principles.Name, physical address, email address, and Social Security number are a few examples of information that falls under this privacy category. Data like health, race, and sexuality may be pertinent to privacy for some companies and service providers, too.
Consider adding to your SOC 2 if:
- Your organization gathers, stores, uses, preserves, reveals, or disposes of personal information.
SOC 1 vs SOC 2
A SOC 1 report is for organizations whose internal security controls can impact a customer’s financial statements. Think payroll, claims, or payment processing companies. SOC 1 reports can assure customers that their financial information is being handled securely.SOC 2 reports help organizations demonstrate their cloud and data center security controls. This security framework is based on the Trust Services Criteria (more on that in a bit).
Both SOC 1 and SOC 2 are attestation reports, where management attests that certain security controls are in place. An independent CPA firm is brought in to verify those claims and either agree or disagree.
Both SOC 1 and SOC 2 also offer Type I and Type II reports.
SOC 2 Type I vs. SOC 2 Type II audits
There are two types of SOC reports:- Type I describes a vendor’s systems and whether their design is suitable to meet relevant trust principles. Examines security controls at a specific point in time.
- Type II details the operational effectiveness of those systems. Assesses those same controls over a longer period of time (typically 6 to 12 months).
SOC 2 Type I is a static point-in-time assessment of your business’s security and compliance posture. An auditor will investigate this snapshot to discover whether or not the right controls are in place. Type I reports are ideal for businesses that need a SOC 2 report as fast as possible.
SOC 2 Type II is a much more in-depth compliance review that takes place across six to 12 months. The auditor will evaluate the evidence collected over this period of time and determine the strength of controls and policies. Type II requires more time and resources, but offers a more meaningful and reliable attestation. Many prospects, especially in the enterprise, will specifically request a Type II report.
SOC 3 vs SOC 2
Both SOC 2 and SOC 3 reports are conducted according to SSAE 18 standards, as outlined by the AICPA. Both reports also involve a CPA audit and rigorous testing of an organization’s security controls.
But there are a few key differences:
- Reporting type: As mentioned above, SOC 2 offers both Type I and Type II reports. SOC 3 reports are always Type II reports.
- Level of detail: SOC 3 Type 2 reports do not include detailed descriptions of the auditor’s control tests, test procedures, or test results. They do contain the auditor’s opinion, management assertion, and system description. Because the report doesn’t go into as much detail as a SOC 2, SOC 3 reports usually won’t satisfy the needs of your customers or their auditors.
- Level of privacy: SOC 2 reports are private, which means they are typically shared only with customers and prospects under an NDA. SOC 3 reports are general use reports that can be distributed freely or posted to the public on an organization’s website.
Which SOC report do you need?
Deciding which SOC report makes the most sense for your company depends on the type of information you’re processing for your customers.
For example, if you’re providing payroll processing services, you’ll most likely need a SOC 1. If you’re hosting or processing customer data, you’ll need a SOC 2 report. SOC 3 reports are less formal and are best used as marketing material.
SOC2 vs NIST CSF 2.0
NIST 800-53 is one of the most robust and prescriptive frameworks, with 18 control families and over 900 controls. The NIST CSF is a subset of NIST 800-53, sharing certain requirements and criteria, while omitting many of the controls more relevant to federal agencies.
The Core is a set of desired cybersecurity activities and outcomes organized into Categories and aligned to Informative References. The Framework Core is designed to be intuitive and to act as a translation layer to enable communication between multi-disciplinary teams by using simplistic and non-technical language. The Core consists of three parts: Functions, Categories, and Subcategories. The Core includes five high level functions: Identify, Protect, Detect, Respond, and Recover. These 5 functions are not only applicable to cybersecurity risk management, but also to risk management at large. The next level down is the 23 Categories (98 Subcategory) that are split across the five Functions. The image below depicts the Framework Core's Functions and Categories.
note: https://www.aicpa-cima.com/resources/article/get-mappings-relevant-to-the-soc-suite-of-services
The mappings are not prepared at a high level and may not identify every difference between the TSC and the other framework. Depending on the service performed, the practitioner should use professional judgment when considering how to address those differences in the engagement. Currently, mappings are available from the TSC to the following frameworks:
I like to think of the NIST CSF as a great foundation for developing your policy statements and standards that form your internal controls, which can then be mapped to the relevant Trust Services Criteria to support your SOC 2 compliance journey.
Take our earlier NIST Subcategory example, and note how it maps to the Trust Services Criteria (note, use the mapping spreadsheet referenced above to easily search by NIST Subcategory reference or SOC 2 Criteria reference):
| SOC 2 mapping to NIST CSF (example) | ||
CSF FUNCTION | CSF CATEGORY & SUBCATEGORY | TRUST SERVICES CRITERIA & POINTS OF FOCUS |
| Protect (PR) | Identity Management, Authentication and Access Control (PR.AC): Access to physical and logical assets and associated facilities is limited to authorized users, processes, and devices, and is managed consistent with the assessed risk of unauthorized access to authorized activities and transactions. PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes | CC6.1: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives.
|
CC6.2: Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.
| ||
The NIST CSF is intended to be a useful tool for organizations looking to design and implement cybersecurity policies and controls that will satisfy multiple regulatory and compliance requirements. If you are a service organization, chances are you still need that SOC 2 report, but the NIST CSF can help you interpret the foreign language that is the Trust Services Criteria and be the “how-to” you’ve been looking for.
SOC2 vs ISO27001 : 2022
SOC 2 and ISO 27001: Attestation vs. CertificationStatement of Applicability (SoA)
In ISO27001 Annex A, you’ll find a list of 114 possible controls. Select those that address the risks you identified in your risk assessment. Then write a statement about which controls you will apply. You will need this document for the audit process.
Checklists
- ISO 27001 Annex A checklist
- ISO 27001 evidence checklist
- ISO 27001 gap analysis checklist
- ISO 27001 surveillance audit checklist
References
- Vanta - Compliance Monitoring Tool
- SOC 2 Controls
- Microsoft Service Trust Portal
- https://wilsonmar.github.io/soc2/ - SOC2
No comments:
Post a Comment