A SOC 2 report assesses an organization’s internal security controls and systems designed to safeguard information. It’s one of the most popular types of assessments, along with a SOC 1 report which evaluates internal controls over financial reporting. Perhaps not as well known, but just as advantageous, is a SOC 3 report.  

In this blog, we’ll explain the details of a SOC 3 report, its applicability, and the benefits it provides to an organization.  

What Is a SOC 3 Report? 

A SOC 3 report is a report on the internal security controls at a service organization addressing matters other than financial reporting. It is prepared following an audit using the SOC Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.  

If a SOC 3 report sounds a lot like a SOC 2 report, it’s because they are essentially the same document with one exception: A SOC 3 report does not provide the security controls nor details of the tests performed by the service auditor (Section 4 of the SOC 2 report). 

In essence, a SOC 3 report is simply a public-facing abridged version of a SOC 2 report. Worth noting, while a SOC 2 audit can be completed as a Type 1 (point in time assessment) or Type 2 (historical lookback assessment), a SOC 3 is only possible as a Type 2.  

A SOC 3 report allows an organization to share their SOC 2 but without publicizing confidential information.  Whereas a SOC 2 report is a restricted-use report and intended for a specific, limited audience, a SOC 3 report can be utilized as a public-facing document meant to generate trust and confidence in an organization’s information security management system.   

The Components of a SOC 3 Report 

There are three main components of a SOC 3 report. These include: 

1. The service auditor’s report on whether the entity maintained effective controls over its system as it relates to any of the categories being evaluated: 

• Security refers to the protection of information throughout its lifecycle. Security controls include a range of risk-mitigating solutions like endpoint protection and network monitoring tools to prevent or detect unauthorized activity. Any SOC evaluation must include the Security Category; it is required unlike the other four Categories. 
• Availability refers to operational uptime and performance to meet stated business objectives and service level agreements. The Availability Category addresses whether systems contain controls to support and maintain system operation, such as performance monitoring, data backups, disaster recovery plans, and environmental protections around any infrastructure hosted onsite. 
• Confidentiality refers to the demonstrated ability to protect confidential information throughout its lifecycle, including collection, processing and disposal. Controls for Confidentiality include encryption, as well as identity and access management, data retention and data disposal. 
• Processing Integrity refers to assurance that data is processed in a predictable manner, free of accidental or unexplained errors. Due to the sheer quantity of controls typically leveraged, Processing Integrity is usually only evaluated at the system or functional level.  
• Privacy refers specifically to Personally Identifiable Information (PII), especially PII an organization captures from customers. The Privacy Category targets controls over communication, consent, collection of personal information, and verifies appropriate parties are able to access PII.  

2. The management’s assertion that the controls were suitably designed and effective to achieve control objectives throughout the specified time period. 

3. A brief description of the aspects of the system assessed so that the boundaries of the system are clear, and the scope of the audit is defined. This is important as an unclear description can lead to confusion as to what exactly the service auditor has evaluated. 

4. Again, a SOC 3 report does not provide information on financial reporting, security controls or details of the test performed by the service auditor.  

The Benefits of a SOC 3 Report 

As a general use report, a SOC 3 can be freely distributed or posted on a website as a seal of an organization’s commitment to information security. This is in stark contrast to a SOC 2 which is a “restricted use report”, meaning that only customers and third parties such as financial institutions, vendors, and user auditors should be granted access to the report upon signing a non-disclosure agreement (NDA).  

Remember, Section 4 of a SOC 2 contains details on the security controls an organization has implemented; it’s something that is best kept confidential. A SOC 3 omits Section 4 and serves as a brief summary of a SOC 2. As such, there are no such restrictions on its use. For this reason, it’s common for organizations undergoing a SOC 2 audit to ask for a SOC 3 report to go along with it.    

As a is a licensed CPA firm and one of the top issuers of SOC 2 reports in the world A-LIGN can be trusted to guide you every step of the way through the assessment process.  

Think you’re ready to evaluate your information security management systems? Check out this article on Five Easy Steps to Get Started With Your SOC 2 Audit. 

The State Risk and Authorization Management Program (StateRAMP) provides state and local governments with a comprehensive security framework designed to improve their cloud security. The continued rise in threat actors targeting critical U.S. infrastructure has led the StateRAMP program to gain momentum. Keep reading to learn how to prepare for StateRAMP Authorization.

Cloud service providers (CSPs) that wish to sell a cloud service offering (CSO) to one or more of these states should achieve StateRAMP authorization — and the list of states that have adopted this program will only continue to grow. 

StateRAMP is voluntary and allows CSPs to benefit from a “do once, use many” approach. This means they can reuse their authorization package across multiple states rather than going through mandatory multiple state assessments.  

How does StateRAMP differ from FedRAMP? 

If StateRAMP sounds familiar, you may have heard mention of the similarly titled FedRAMP (the Federal Risk and Authorization Management Program).   

Created in 2011, this framework was designed to provide a standardized approach to the security assessment, authorization, and continuous monitoring of cloud products and services. By promoting the adoption of secure cloud services across the Federal government, FedRAMP empowers agencies to use modern cloud technologies, with an emphasis on security and protection of federal information. 

StateRAMP can be thought of as FedRAMP for state and local governments, and it has a Security Assessment Framework that is based on the National Institute of Standards and Technology Risk Management Framework (NIST RMF).  

However, whereas FedRAMP has a notoriously difficult authorization process, CSPs can expect a more business friendly process for StateRAMP. There is even a fast track to StateRAMP authorization for FedRAMP authorized services. 

Requirements for StateRAMP authorization 

CSPs seeking StateRAMP authorization must comply with four primary requirements. These include:   

• Compliance with the security standards listed in NIST Special Publication 800-53 Rev 4, and soon 800-53 Rev 5.  
• A relationship with a Third-Party Assessment Organization (3PAO) that serves as a partner and educator throughout the entire process. 
• Producing an in-depth security report in collaboration with a 3PAO that proves the organization has all the necessary controls in place and meets all requirements for authorization.   
• Participating in continuous monitoring to demonstrate that the organization continues to maintain StateRAMP compliance.   

How organizations can prepare:

For CSPs in the process of acquiring StateRAMP authorization, as well as those still determining their next move, there are four steps that can be taken now to ensure your transition process is as smooth as possible.   

1. Adhere to the StateRAMP implementation checklist  

StateRAMP has created its own detailed implementation checklist. From identifying stakeholders and determining a governance process, to identifying continuous monitoring and reporting requirements, this guide provides CSPs with a solid “at-a-glance” checklist.  

Each step of the process is broken down into smaller sections, allowing CSPs to understand the government’s reasoning for the required action and who is involved with each component.  

2. Address gaps against the StateRAMP control baseline 

In addition to the implementation checklist, StateRAMP also has a baseline summary of their security controls.  

All of the security controls are listed in the annually updated table, and are outlined in NIST 800-53 Rev. 4, which, as a reminder, is required for FedRAMP.  

• StateRAMP Category 1 aligns with the controls required for FedRAMP Low Impact.  
• StateRAMP Category 3 aligns with the controls required for FedRAMP Moderate Impact.  
• StateRAMP Category 2 is in development. It is intended to provide flexibility for state and local governments.  

3. Follow the StateRAMP guide for continuous monitoring and improvement  

Monitoring security controls is a critical part of the overall risk management framework for information security. Service providers are required to maintain a security authorization that specifically meets StateRAMP requirements. 

An easy method for ensuring CSPs continue to routinely examine the proper areas is to follow StateRAMP’s official guide for continuous monitoring and improvement. Ongoing due diligence and review will enable you to make informed risk management decisions regarding the security of your cloud solutions.  

4. Leverage control inheritance from a StateRAMP-authorized infrastructure provider 

StateRAMP routinely updates its Authorized Vendor List (AVL), which lists products that achieved a security status along with products actively going through the process. Working with these vendors can help streamline your own authorization journey.  

Now is the time to act 

The rate of StateRAMP adoption by state and local governments will only continue to increase. StateRAMP allows CSPs to maintain a single authorization standard rather than the multiple variants from state to state. If your organization can benefit from reusing their authorization package across multiple states rather than going through mandatory multiple state assessments, A-LIGN’s experts can help you begin preparing. 

Achieve StateRAMP authorized status from A-LIGN, one of the only StateRAMP-registered assessors on the market today.  

As you are probably aware, the Payment Card Industry Security Standards Council (PCI SSC) announced it would be phasing out the Payment Application Data Security Standard (PA-DSS) this year, which has been in place since 2008 for a new framework called PCI SSF (Payment Card Industry Software Security Framework).   

Introducing a Modern, Modular Security Assessment  

PA-DSS was created from the Visa’s Payment Application Best Practices (PABP) standard to help software vendors develop secure payment applications that remain in compliance with the Payment Card Industry Data Security Standard (PCI DSS).  The PCI DSS framework is a set of security standards to ensure all companies maintain a secure environment that have the ability to transmit, process, store or can affect the security of the credit card information.   

The intention of the PCI DSS framework standards is to give organizations that require payment applications a level of assurance that an application can be run in a compliant manner. It also provides clear instruction from the vendor to the software user on how the software should be configured to be compliant.   

Certification via PA-DSS provides validation for a three-year cycle and is specific to assessed versions of software and to the platform it was tested on — meaning that every time a new major version is released or new platform is supported, PA-DSS would require a full validation and submission to the PCI SSC.  

Since its development in 2008, the payment industry has changed drastically. Today there are a variety of different technologies to consider, like kiosk systems and cloud systems, among others. Even mobile applications were in their infancy at the time PA-DSS was developed. As a result, this standard became more limited as it did not allow for a lot of flexibility to accommodate newer payment technologies. Given this, a new and more modular framework was needed to encompass the security needs of more application types.   

Introducing PCI SSF, which modernizes the assessment process and allows for more flexibility and development in the future. A key change within SSF is a separation of the secure development lifecycle and the secure software assessment into two different assessments. This change allows organizations to validate their Secure Software Lifecycle and ensure proper controls are in place prior to reviewing any specific application. It also offers vendors that complete a Secure Software Lifecycle validation more flexibility to perform their own delta assessments and report back to the PCI SSC directly for those applications assessed under the Secure Software program and can reduce the need to engage an SSF company every year.  

The new PCI SSF includes two fundamental components:   

• The Secure Software Lifecycle (Secure SLC) Assessment which applies to the software development lifecycle of the organization developing a payment application  
• The Secure Software Assessment which covers the security of specific payment software packages itself   

It’s important to note that these two components are mutually exclusive, and while an organization may require an assessment of its payment application, it does not necessarily require a separate assessment of the entities Secure Software Lifecycle. However, there are benefits gained from obtaining a Secure SLC validation prior to assessing individual software packages under the Secure Software Assessment from incentives the council provides to vendors who achieve both compliance validations.    

So, what does this mean for you? Let’s take a deeper look at the Secure Software Lifecycle (Secure SLC) portion of the new framework.   

The New PCI SSF: Secure SLC Standard  

The Secure SLC portion of the PCI SSF addresses the development practices under which software products are built. The standard calls for proper policies and documentation, rigorous testing, training, and other secure development controls to help software vendors protect sensitive data, minimize vulnerabilities, and defend software from attacks throughout the entire development lifecycle.   

The Secure SLC requirements apply to more than just development practices; they also extend to the technologies used and any personnel involved in design, development, deployment, or maintenance of the software product.   

To pass assessment under the new Secure SLC guidelines, vendors must adhere to requirements categorized into four main sections:  

1. Software Security Governance   

A formal governance program must be established to demonstrate the vendor’s commitment to building secure software and protecting sensitive data. The governance program must include clearly assigned responsibilities throughout the team and ensure that team members have the proper skills and training for their role. Further, the program must ensure that the vendor properly identifies and monitors relevant security and compliance requirements and documents specific rules related to how products will be developed in a secure manner.  

2. Secure Software Engineering  

This section of the requirements focuses on protecting critical software assets and ensuring software is resistant to attacks. Threats to software design must be continuously identified and assessed throughout the development process, and controls must be put in place to minimize those threats. There are also a variety of elements included in this section of the requirements related to detecting and fixing vulnerabilities in a timely manner.  

3. Secure Software and Data Management  

To comply with this section of the requirements, vendors must have a process in place to identify, assess, and approve software changes, and formally track software versions. An additional component to this section is to set boundaries around data collection. Doing so ensures that software vendors only collect and retain data throughout the development process when there is a legitimate business or technical need.   

4. Security Communications  

To comply with the Security Communication aspect of the Secure SLC requirements, vendors must set up proper communication channels to receive information about security issues and report information about mitigation options in a timely manner to all necessary parties. This section also calls for a summary of changes to be provided to stakeholders upon release of any software updates.  

Exploring PCI SSF’s Modular System   

As we mentioned, the new PCI SSF also includes a Secure Software Assessment. The Secure Software Assessment is a modular system and includes variable certification elements for different types of products as it relates to the security of the payment software itself.   

The combination of the Secure SLC and the Secure Software Assessment allows the program, as a whole, to accommodate the evolving landscape of payment applications and services. It enables any newly developed applications to leverage these controls to help ensure an organization’s compliance to the secure software standard. It also provides a benefit allowing organizations to submit their own annual revalidation for administrative and low impact changes (Delta changes) and submit those directly to the PCI SSC without requiring review and submission by a PCI-qualified Secure Software Assessor Company.   

Those software vendors that are not a Secure SLC Qualified vendor, will require a Secure Software Assessor to submit their Delta reviews. For all software vendors, high impact changes will require a full software validation by a Secure Software Assessor Company.   

How to Prepare for Secure SLC and the Secure Software Assessment  

For existing PA-DSS certified software vendors, our team can also assist you with mapping a transition to the new framework promptly, so you can maintain compliance without risking any gaps after PA-DSS is officially expired in October 2022. Always remember, those who engage early have a significant advantage. Organizations often underestimate the amount of effort required or have competing priorities that come up at the last second, which leads to project delays. So getting ahead of this change will ensure no negative impact on your current listings and help you manage this transition so it goes smoothly. The PCI SSC reviews for each submission can take some time, so plan ahead to ensure you maintain compliance in a timely manner.   

The best thing you can do to make sense of the new requirements and prepare for the Secure SLC and/or the Secure Software assessment is find a true partner that is certified as a Secure Software Assessor Company, such as A-LIGN, to help your team. Our team of experts have years of development experience and have met the rigorous new standards set forth for all SSF assessor companies.   

We also will utilize our existing technologies, such as A-SCEND, to help manage the assessment process from start to finish and help streamline the assessment process for your organization. This gives us the ability to map all common controls within our A-SCEND platform between both the Secure Software Lifecycle and Secure Software Assessment and with other standards as well, such as the new NIST 800-218. Our A-SCEND platform will put you in a better position to meet new compliance demands that your customers or partners bring to you in the future.  

Keep an eye on our blog for a follow-up post where we dive into the Secure Software Assessment aspect of PCI SSF in more detail.  

Does your organization need assistance mapping your approach to the new PCI SSF before your current PA-DSS application officially expires? A-LIGN’s Qualified Security Assessors (QSA) are available now to assist you with any of your PCI SSF needs. Contact us today at [email protected] or 888-702-5446.  

On March 31, 2022, the PCI Standards Security Council (PCI SSC) updated the PCI Data Security Standard (PCI DSS), which is the information security standard used by retailers and financial organizations to protect sensitive cardholder data. Coming four years after the release of PCI DSS v3.2.1, the Council says PCI DSS v4.0 will “address emerging threats and technologies, and enable innovative methods to combat new threats” to cardholder data largely by centering the standard on outcome-based requirements. 

Hundreds of pages longer than the previous version, the new standard is considered a major update and is a significant revision that might seem foreign even to those familiar with PCI DSS v3.2.1. Organizations can expect most requirements to have some level of alteration — from changes to requirement number, location, and wording, to new requirements and testing procedures.  

One of the most noteworthy updates is to the reporting documentation itself, which includes a new assessment finding status (i.e. In Place with Remediation) and a new validation method called “Customized Approach.” 

In this blog, I’ll offer a high-level overview of what you need to know about the PCI DSS 4.0 changes.  

PCI DSS 4.0 Changes

PCI DSS v4.0 maintains its core structure of 12 PCI DSS requirement sections. However, it features significant changes to the requirement layout and in many cases to the wording itself. Some requirements were relocated to new sections to better suit its purpose and objective. You will also find requirements that have been redesigned to better clarify its security intent and provide additional guidance on how security controls should be implemented. 

The key high-level goals for PCI DSS v4.0 are: 

• Ensure the standard continues to meet the security needs of the payments industry 
• Promote security as a continuous process 
• Add flexibility and support for additional methodologies to achieve the objective of a requirement 
• Enhance validation methods 

The Customized Approach 

PCI DSS 4.0 keeps the existing prescriptive method for compliance and introduces a new Customized Approach option for meeting a requirement. Customized Approach allows customers to leverage novel technologies and innovations to meet a control objective that may not necessarily meet the defined requirement approach. This is intended to give organizations more flexibility as long as they can show their custom solution meets the objective of the PCI DSS requirement.   

The new Customized Approach validation method provides a more mature model from what was previously referred to as Compensating Controls. It requires more vetting and review, including control matrix documentation, and a targeted risk analysis to ensure the assessed entity has fully addressed all associated risks and to confirm the intent of the control objectives are being met.  

12 Additional Changes You Need to Know 

Outside of the changes to the reporting format and validation methods, there are a good number of changes to the requirements themselves as well.  There are a total of 64 changed or new requirements in the PCI DSS 4.0 standard. Here are 12 PCI DSS 4 changes you need to know.  

1. Formalized Annual Scoping Exercise – Performance of an annual scoping exercise was something organizations were instructed to execute within the PCI DSS 3.2.1 instructions. The onus however was on the organization being assessed to confirm this exercise was being properly conducted. PCI DSS v4.0 formalizes this requirement which will now be validated by an assessor as one of the new requirements within the standard itself. 

2. Updated Authentication Requirements – Password Authentication Requirements now include: 

• Minimum Password Length – 12 characters (previously 7 characters) 
• Minimum Complexity – numeric and alphabetic 
• Lockout Requirements – no more than 10 failed attempts (previously 6 attempts) 
• Minimum Lockout Duration – 30 minutes 
• Password Expiration – 90 days* 
• Password History – Previous 4 Passwords 

*PCI DSS v4.0 does provide additional options to satisfy the 90-day expiration requirement. It clarifies the use of MFA and/or performing a real-time dynamic analysis on a user account’s security posture based on a zero-trust architecture can also be used to meet this control.  

3. Multi-Factor Authentication – PCI DSS 4.0 adds clarification to requirements for MFA for remote access and access into the cardholder data environment (CDE). If remote access grants access outside the CDE, then an additional MFA control will be required to gain access into the CDE from that network. This is important because the new standard also clarifies that MFA for remote access is also required for networks with access to the CDE (where connected systems exist). 

4. Risk Assessment – Instead of a single risk assessment process, PCI DSS v4.0 requires organizations to perform targeted risk analysis for all requirements where there is flexibility allowed and that risk analysis must be performed at least annually for each instance. An example of this are controls that are required to be performed “periodically.” The results of this exercise will need to be documented and provided to the assessor for review prior to the PCI assessment.   

5. Ownership, Roles, & Responsibilities – Organizations must now properly communicate roles, responsibilities, and ownership of all requirement tasks. Responsibilities must be formally documented, assigned, and understood by the owner. 

6. Encryption – The hashes used to render a ​​primary account number (PAN) unreadable are required to be keyed cryptographic hashes of the entire PAN. Organizations will no longer be allowed to only hash the sensitive parts of the PAN. In addition, disk encryption will no longer be acceptable as the control used to protect PAN at rest, with the exception of PAN stored on removable media.  

7. Anti-virus/Malware – The anti-virus requirements will have more flexibility for organizations based on targeted risk assessments. There is a new control required to be in place that detects and protects personnel against phishing attacks.   

8. Public-facing web applications – PCI DSS v4.0 requires deployment of an automated technical solution that continually detects and prevents web-based attacks. This solution must be in front of public-facing web applications and configured to either block web-based attacks or generate an alert that is immediately investigated.  

9. HTTP Headers – To help curb the impact of Magecart attacks, there’s a new requirement for a change and tamper-detection mechanism that alerts of any unauthorized modifications to HTTP headers and the contents of payment pages as received by the consumer browser.  

10. Payment page scripts – Also related to the above, organizations will be required to manage (and use proper controls to ensure the integrity of) all payment page scripts that are loaded and executed in the consumer’s browser. This includes scripts being pulled from third-party sites.  

11. Log Requirements – Only ‘Automated Mechanisms’ will be allowed for performing audit log review, meaning daily manual reviews will be prohibited.  Also, requirements around control failures will now apply to all organizations and not only service providers.   

12. Internal Vulnerability Scanning – Internal scans must be authenticated unless the device being scanned does not accept credentials. PCI DSS v4.0 also includes controls concerning the protection of authentication credentials.   

PCI DSS v4.0 Timeline 

PCI DSS v4.0 and PCI DSS v3.2.1 standards will both be valid standards available to organizations until March 31, 2024. After which, only PCI DSS v4.0 assessments will be allowed. Also, most new requirements (which include others not listed above) will be a best practice until 2025.  

The PCI SSC is still working to release supporting documents to assessor companies and provide training to all assessors before they can perform any PCI DSS v4.0 assessment. This training is planned to be available in June 2022. Given this, we don’t expect any PCI DSS v4.0 assessments to begin until at least July of 2022. We caution companies, however, to do their due diligence and prepare for any and all changes to the standard that might impact their assessment.   

If you have any questions about the new standard and need help deciding which will be most appropriate for you to complete, please reach out to A-LIGN and our team will be happy to share more about the PCI DSS 4 changes and help you through that decision process.   

The Cloud Security Alliance Security, Trust, Assurance, and Risk (CSA STAR) program and the accompanying Cloud Controls Matrix (CCM) form a world-renowned cybersecurity assurance framework that cloud service providers (CSPs) can use to demonstrate they follow best practices that support secure cloud computing.  

If your business currently has (or plans to pursue) CSA STAR certification, you should be aware that CCM v3.0.1 is in the process of being replaced by CCM v4. Below are the key dates you need to know for this transition as well as the primary differences between CCM v3.0.1 and v4.  

CCM v4 Transition Timeline  

CSA is still accepting CCM v3.0.1 for some submissions as v4 is phased in, but will require everyone to use v4 by the beginning of 2023. For this reason, CSPs that have yet to make the switch to v4 should start doing so sooner rather than later.  

The full timeline for the transition to CCM v4 is as follows:  

• August 2021: Began accepting both v4 and CCM v3.0.1 for all STAR Levels.  
• December 2021: Began requiring CCM v4 for all new Level 2 submission.  
• July 2022: Will begin only accepting CCM v4 for all Level 1 and Level 2 submissions.  
• January 21, 2023: CCM v3.0.1 will be officially withdrawn.  

This means if a certified STAR auditor performs a new CSA STAR Level 2 certification submission (Level 1 is a self-assessment that does not result in certification) on behalf of your organization, it will be against CCM v4.  

However, if your organization currently has a certification or attestation listed on the official CSA STAR registry, you technically won’t be required to demonstrate conformity to CCM v4 until your next renewal audit. Renewal audits happen annually for SOC 2 + CSA STAR Attestations and every three years for ISO 27001:2013 + CSA STAR Certifications as well as GB/T 22080-2008 + CSA C-STAR Assessments. To determine whether or not this is needed, reach out to your CSA STAR auditor and determine if it’s worth planning to accelerate or adjust any elements of the official transition timeline.  

CCM v3.0.1 vs. CCM v4  

It’s important to understand the why behind the CSA’s decision to release a new edition of the framework to replace the previous version that had been in place since 2014. In the CSA’s own words, CCM v4 was developed in order to:  

• Ensure coverage of requirements deriving from new cloud technologies (e.g., microservices, containers) and new legal and regulatory requirements especially in the privacy realm. 
• Improve the auditability of the controls and provide better implementation and assessment guidance to organizations. 
• Clarify the allocation of cloud security responsibilities within the shared responsibility model. 
• Improve interoperability and compatibility with other standards.  

To accomplish these goals, CCM v4 includes modified security domains and additional controls. It has 197 control objectives over 17 domains, compared to the 133 control objectives over 16 domains contained in CCM v3.0.1.  

The modified domains are Governance, Risk Management and Compliance, Audit and Assurance, Universal Endpoint Management, and Cryptography, Encryption, and Key Management. The new domain, Logging and Monitoring, was added to address the increase in ransomware and other cyberattacks.  

Data privacy is also on the rise as an area of top security concern, which is why CCM v4 features a greater focus on Privacy Lifecycle Management. This domain was only limited to privacy matters related to bring-your-own-device (BYOD) work policies under CCM v3.0.1. Together, all of the new and modified controls help CSPs adopt international cybersecurity best practices that are specific to cloud security and data privacy.  

New supporting documentation  

CCM v4 also introduces a few pieces of supporting documentation CSPs can use to gain clarity around the certification process and what they need to do to prepare. These documents include:  

• Implementation Guidelines: Explains how to implement the various CCM controls, created by the CCM Working Group.  
• Control Applicability Matrix: Helps CSPs delineate security responsibilities between themselves and their customers  
• Auditing Guidelines: Intended to be used by auditors, this guide is useful for CSPs looking to understand how their security will be assessed under an official audit.   

CAIQ v3.1 vs. CAIQ v4  

The Consensus Assessments Initiative Questionnaire (CAIQ) is based on the best practices listed in the CCM. It serves as the self-assessment a CSP must submit to the registry to earn CSA STAR Level 1. The CAIQ is also a prerequisite for pursuing CSA STAR Level 2 under the official Code of Practice.  

Just as the CCM was modernized with v4, the CAIQ has been updated (also to v4) to align with all of the changes mentioned previously. CAIQ v4 replaces CAIQ v3.1, which itself was a minor update to the previous CAIQ v3.0.1. There are two primary changes that are worth noting when comparing CCM 3.1 and CCM v4.  

First, CAIQ v4 has lowered the total number of questions to 261 (down from 310 in v3.1). Even though CCM v4 added more control objectives, the CSA was able to reduce the amount of questions on the CAIQ through improved alignment and reduced redundancy.  

The second significant change is the addition of new columns related to the Shared Security Responsibility Model (SSRM) which allow CSPs to give a more detailed description of who is responsible for implementing each control — the business or its customers. There is one mandatory multiple-choice column where the business must specify if each control is:  

• CSP-owned  
• Customer-owned  
• Outsourced to a third party  
• Shared between the CSP and customer  
• Shared between the CSP and third party  

There are also a few optional columns a CSP may fill out to further elaborate on how they are satisfying their requirements and what they expect their customers to do to comply with their responsibilities.   

Level Up Your CSA STAR Certification  

CCM v4 enables CSPs to stay at the forefront of cloud security best practices. CSA STAR certification helps prove you follow the key CCM principles through an assessment carried out by an independent third-party auditor. Don’t delay in getting up to speed with CCMv4 as the assessment will bring your partners, prospects and customers peace of mind.   

If you are currently in the SOC 2 + CSA STAR Attestation process or have an upcoming engagement and would like to understand where your organization stands, A-LIGN can perform a gap assessment to identify what areas will need additional information based on the recent changes.  

Privacy laws are gaining traction across the globe because companies and consumers alike are more concerned about data privacy than ever before. We’re seeing sweeping legislation across countries — like the EU’s General Data Protection Regulation (“GDPR”), China’s Personal Information Protection Law (“PIPL”) and Brazil’s Data Protection Law (Lei Geral de Proteção de Dados or “LGPD”), as well as more granular laws going into effect in states across the United States, such as the California Privacy Rights Act (“CPRA”), Colorado Privacy Act (“CPA”), and the Virginia Consumer Data Protection Act (“VCDPA”). 

The rise of privacy laws is having a significant impact on compliance programs. Compliance experts now need to stay on top of evolving legislation and implement processes and procedures across their organizations to comply with each new law. This involves an effort in education, as well as, execution.  

To make matters even more complex, organizations must often balance multiple privacy laws — catering to customers in different regions, or to corporate offices spread throughout various jurisdictions foreign and domestic. Breaking down the components of each law and ensuring that an organization has the proper processes in place to meet each requirement is a time consuming and costly process. This is amplified when that effort includes multiple pieces of legislation that must be accounted for.  

With so many different legal requirements to consider, it’s essential to stay organized in your approach to tackling privacy law compliance. That’s why we suggest starting with a gap analysis. 

What is a Gap Analysis? 

Just as it sounds, a gap analysis is used to identify gaps between the requirements of a law and the processes and controls currently in place within your organization. This is typically the first step organizations take on the road to compliance with ISO certifications, SOC examinations, and more. 

Conducting a gap analysis for privacy laws specifically allows you to proactively identify data security risks and ensure your policies and procedures are in compliance with the laws that impact your organization. This has major benefits for your business: Identifying compliance gaps prevents your organization from being subject to expensive regulatory fines and provides a tangible asset for you to furnish to regulators that demonstrates your compliance actions. A gap analysis also serves as a tool to help your organization decide how to allocate resources for privacy and data management projects. The gaps identified can be structured into a roadmap, which provides your organization a blueprint for compliance priorities.  

A Step-by-Step Guide 

In order to conduct a gap analysis, you’ll need to understand all of the privacy laws that impact your business. This may include regional laws — like the California Privacy Rights Act (“CPRA”)— and industry specific laws like HIPAA or FedRAMP. Once you have an understanding of the legal landscape that you’re operating within, you’ll be able to follow the steps outlined below.  

1. Identify Legal Requirements: List all of the applicable standards within relevant laws. Be sure to include all controls or requirements included within each section/clause of the law. 
2. Note Your Existing Policies: Identify all of your business’ relevant privacy policies, outlining the procedures and practices your organization follows to collect data, manage data, secure data, manage employee access to data, etc. 
3. Look for Overlaps: Match the above two items together to identify which policies, procedures and controls cover the identified legal requirements. 
4. Identify Gaps: Identify sections of each applicable law that your organization does not have a corresponding privacy practice, policy and/or procedures in place to address.  
5. Chart Your Next Steps: Establish a plan to implement or update policies, procedures and controls to cover the identified gaps. 

Managing Privacy Laws Cohesively 

As we mentioned previously, many organizations must comply with various legal requirements in order to cater to customers located in different jurisdictions around the world. Pieces of legislation often overlap with one another — expressing the same requirement or sentiment in a different form, article, or legal statement present within the law. If organizations aren’t careful to recognize these overlaps, it can lead to unnecessary (and expensive) duplication of work.  

A gap analysis can be a useful tool when managing laws cohesively. By outlining each control or requirement within the law — instead of just looking at the legislation in full — it becomes easier to identify duplicate pieces and parts of different laws, and see areas that your organization already covers or is working to cover. This is another application of the gap analysis approach, which can save time and money for your organization. 

Get Started Today 

To get the most out of a gap analysis, it’s best to work with an auditing firm who has a deep understanding of the legal requirements of each section of the privacy legislation that impacts your business. That way, the policies and procedures in place at your organization can be properly assessed for compliance.  

A-LIGN is a trusted partner that provides gap assessment services such as for the GDPR, the CCPA, ISO/IEC 27701:2019 and HIPAA. In addition, A-LIGN can perform a gap assessment to grade how your organization collects, stores, shares, protects and maintains sensitive information.  

Let our expert auditors conduct a gap analysis to ensure your partners comply with every necessary piece of legislation.  

Is your organization planning for a SOC 1 or SOC 2 Type 2 report and you’re concerned about the impact of testing exceptions?  You’re not alone.  SOC reports are gaining in popularity across industries and across the globe. An increasing number of customers are asking for demonstrated SOC compliance, and independent cybersecurity control validation and attestation is becoming necessary to compete for high priority contracts.  

Let’s review the difference between a SOC 1 and SOC 2 report, learn why a Type 2 report is valuable, and understand the impact of testing exceptions in final reports. 

What Is a SOC 1 Report? 

A SOC 1 report follows the guidance outlined in the Engagements (SSAE), which focuses on the internal controls that have an impact on the financially relevant systems and reporting. The main goal of a SOC 1 report is to ensure the controls identified by the organization are in place and/or operating effectively to appropriately address the risk of inaccurately reporting financials. 

What Is a SOC 2 Report? 

Like a SOC 1 report, a SOC 2 also follows the guidance outlined in the SSAE. A SOC 2 report focuses on organizations whose services would have an indirect impact on the financial statements of the end user (their customers), whereas SOC 1 is specifically for organizations whose services would directly impact the financial statements of end users.

What is a SOC Type 2 report? 

For a SOC Type 2 report, your organization’s controls are assessed over a period of time, typically a twelve-month review period. A Type 2 report acts as a historical review of your environment to determine and demonstrate if the controls are suitably designed and in place, as well as operating effectively over time. The audit process will include sample testing within the review period to determine if your organization’s controls are operating effectively.  

For example, we will take a sample of employees from the population of terminated personnel and confirm that their access was properly revoked and documented via the ticketing system during the agreed-upon review period. 

A Type 2 report has the following characteristics: 

• Description of your organization’s system as a whole 
• Assesses the design of your organization’s controls, as well as their operating effectiveness 
• Focuses on a period of time in which the controls are operating 
• Features detailed descriptions of the auditor’s tests and test results of the controls 

What are SOC Testing Exceptions?  

Although you can’t “fail” your SOC report, it can result in report opinions to be noted as ‘modified’ or ‘qualified’.  

If the evidence required by a SOC examination has been successfully submitted and accepted by the service organization, the service auditor would issue an ‘unqualified’ opinion.  But, if the service auditor found exceptions amounting to the conclusion that a specific control objective (SOC 1) or criteria (SOC 2) was either not in place or was not operating effectively, the service auditor would issue a qualified opinion. 

There are several reasons why a qualified opinion may occur, including: 

• Management’s description of the system is not fairly presented in all material respects 
• The controls are not suitably designed to provide reasonable assurance that the control objectives or criteria stated in the description of your organization’s system would be achieved if the controls operated as described 
• The controls did not operate effectively throughout the specified period to achieve the related control objectives stated in the description of your system 
• The service auditor is unable to obtain sufficient, appropriate evidence 

Received a Modified or Qualified Opinion? Next Steps 

You’ve been issued a modified or qualified opinion from your service auditor. Now what? It is important to immediately assess the risk of any exceptions noted in both a Type 2 SOC 1 and SOC 2 report. Once your security team has assessed any risks, you should identify compensating or risk mitigating controls.  

If exceptions in tests of controls have been identified, your management team should disclose any known causative factors, the controls that mitigate the effect of the deviations, corrective actions taken, and other qualitative factors that would assist users in understanding the effect of the exceptions. 

User entities should determine how any exceptions could impact the financial statements in question for a SOC 1, or in the case of a SOC 2, the user entity should assess the service organization’s ability to meet service level agreements. 

Preparing for Your SOC Exam 

If you’re undergoing a SOC 1 or SOC 2 audit for the first time, we highly recommend that you complete a Readiness Assessment which will identify high-risk control gaps, provide recommendations for improving controls, and allow you to remediate issues prior to the official SOC audit. 

As a licensed SOC 1 and SOC 2 auditing firm with more than 20 years of experience, and as the top SOC 2 report issuer in the world, A-LIGN has the people, process, and platform you need to help your organization reach any of your compliance needs. 

A-LIGN’s Compliance Crosswalk podcast features discussions at the intersection of security, privacy, compliance, and risk management. On the premiere episode, hosts Blaise Wabo, Healthcare and Financial Services Knowledge Leader, and Arti Lalwani, Risk Management and Privacy Knowledge Leader, share their thoughts and insights on the state of cybersecurity after the pandemic.  

Remote Work Threatens Cybersecurity  

The world has changed as a result of the pandemic with people working from the office, home, the beach, local coffee shops, basically anywhere. But what does this mean for cybersecurity with employees accessing networks that might not be as secure as the one at the workplace? In short, increased risk.  

A virtual private network (VPN) can help mitigate that risk, provided that employees use it every time they hop onto an offsite network. Companies can better protect themselves by updating their remote work policies regarding connecting to offsite networks, and implementing controls so that risks aren’t exploited by bad actors.  

“Communication is key,” Arti says. “Who do you go to when breaches happen?” Blaise recommends organizations look into installing mobile device management or mobile app management software on work devices. The technology enables IT administrators to control, secure, and enforce policies on devices, adding another layer of risk mitigation. 

The Rise and Risks of Telemedicine  

In addition to remote work, another trend that resulted from the pandemic is the acceleration of telemedicine. Blaise notes that from 2019 to 2021, telemedicine increased by 2,000%. While telemedicine enabled patients to receive care when going to see a doctor was unsafe or impossible during the most precarious moments of the pandemic, it has become a target for cybercrime. Thus, precautions must be taken to enhance security around sensitive patient data.    

With privacy as an ongoing concern in telemedicine, providers must be more proactive about getting consent on information they retain during a session. They must also take measures to secure virtual communications. It’s vital (and the law) that applications used during the virtual meetings are compliant with HIPAA regulations.  

Additionally, providers and patients should ensure that telemedicine apps completely remove sensitive data that might have been stored. Simply deleting apps from a device doesn’t necessarily mean the data has been completely eliminated.  

Financial Fraud 

During the pandemic, consumers significantly increased the use of e-commerce. Even those that might have been wary of putting their credit card information on the internet found themselves placing orders on Amazon and other online retailers. While it was convenient and served as a lifeline to both retailers and consumers, it was a boon to hackers as well.  

“I believe the instances of credit card fraud increased over the last two years,” says Blaise. Arti understands this all too well, saying that she had to change her credit card number four times over the last two years purely due to cybersecurity breaches. Her recommendation: Set up alerts! 

For organizations looking to secure sensitive financial information, Blaise recommends encrypting data and using binary encryption keys. These allow for authorized decryption, but if hackers managed to decipher part of the key, they won’t have access to all of it. 

Put a Plan in Place 

Leveraging a cloud infrastructure to host organizational data will also help reduce the risk of hacking. Most companies don’t have the resources to properly secure on-site servers, but the major cloud providers (AWS, Azure, IBM, Google) all meet best-in-class compliance standards and stay updated with the latest security certifications.  

But even the largest of cloud providers can go down, as the world discovered in December when AWS suffered three outages affecting companies like Slack, Imgur, and Asana. Arti says that organizations should institute a business continuity plan relevant to each location in the event their website is forced offline due to a technical mishap, security breach, or even weather-related disaster.  

Plans should also address the issue of ransomware attacks, which are on the rise and require organizations to pay money to retrieve control of their IT network from hackers. Going through an external penetration test can expose network vulnerabilities. Also, getting key personnel in the same room and running tabletop exercises and conducting a ransomware preparedness assessment on how to respond to a cybersecurity incident will help prepare team members should an attack actually occur.  

Putting a plan in place can also be greatly beneficial for employee turnover, a trend that we saw emerge toward the end of the pandemic. 

The Great Resignation Hits Compliance 

The compliance field isn’t immune to the Great Resignation, as the pandemic has caused workers in the field to reassess how work fits into life. Organizations must recognize their team members as human beings first with full lives, and not just employees. “We don’t live to work anymore. We work to live,” says Arti. Companies need to rethink their culture going forward so that employees are thriving personally and professionally. 

Companies looking to fill cybersecurity and compliance roles will need to assess their talent needs in light of the labor shortage. They won’t find that defined ideal candidate with the desired 10 years of industry experience. Instead, they should consider a candidate who might be green, but can bring other skill sets to the table. It then falls on the company to provide initial and regular training to keep employees updated on ever-changing compliance requirements. As an added benefit, broadening the candidate pool can also help in recruiting more diverse talent who can bring new insights and add to a healthy company culture.  

Join Blaise and Arti in May for episode two of the Compliance Crosswalk podcast.  

For nearly two decades, the data economy has hidden behind a “digital curtain” that cloaked organizations’ sometimes dubious practices from lawmakers and the public. It was the wild west, where companies could do whatever they wanted with consumer data. That curtain has since been lifted as a result of consumer mistrust, government regulations, and market forces.  

Privacy is top of mind for consumers and a priority for government. As such, organizations that handle personal data are having to take action to affirm their commitment to data security and comply with a growing set of regulations.  

Government Actions  

For years, organizations made the rules when it came to data privacy. But in the wake of costly data breaches, and sometimes at the behest of consumer advocacy groups, governments are steadily increasing their focus on securing data privacy.  

General Data Protection Regulation (GDPR)  

General Data Protection Regulation (GDPR) is designed to protect the data of European Union residents. It is an update to the outdated Data Protection Directive, enacted in 1995. Unlike the directive, which every EU nation could customize to their own country, the GDPR requires all 27 member states of the EU to comply with the binding regulation. 

The problem with the earlier directive was that it failed to address how data is stored, collected, and transferred in an age where information is increasingly digitized. Simply put, it didn’t keep up with the speed of technological advancement, so new regulation was required. Failing to properly comply with the GDPR can be extremely costly, and some of the world’s most recognized companies have been slapped with hefty fines when they were found to have broken the regulations:   

• Amazon was fined a whopping $877 million for issues related to cookie consent.  
• WhatsApp was slammed with a $255 million fine for failing to properly explain its data processing practices in its privacy notice. 
• Google was hit with a $102 million fine for not making it easier for YouTube users to refuse cookies.  

California Privacy Rights Act (CPRA) 

An evolution of the 2018 California Consumer Privacy Act (CCPA), the new California Privacy Rights Act (CPRA) began as a ballot initiative promoted by the data privacy advocacy group Californians for Consumer Privacy. The group gathered enough signatures to qualify its proposition for a new privacy law on the 2020 ballot. California voters approved Proposition 24, which set the stage for CPRA to become state law. 

The CPRA is a data privacy bill that takes effect on January 1, 2023 and becomes fully enforceable on July 1, 2023. The new CPRA is more comprehensive than the CCPA. It strengthens data privacy rights of California residents, tightens business regulations around the use of personal information (PI), and establishes a new government agency for state-wide data privacy enforcement called the California Privacy Protection Agency (CPPA). 

Inspired by California, Colorado and Virginia have also signed privacy bills into law. More state legislation is expected on the horizon as all but 11 statehouses are discussing bills at some level to govern the use of personal information.   

Personal Information Protection Law (PIPL) 

On August 20, 2021, China passed the Personal Information Protection Law (PIPL) which provides Chinese citizens privacy protections and rights over their personal information. The comprehensive privacy and data protection law took effect on November 1, 2021. 

The legislation comes as China increases regulatory scrutiny on technology companies and other entities handling large troves of sensitive public data. As an example, the government cracked down hard on rideshare company DiDi because it wasn’t satisfied with its data security and privacy practices.  

While some refer to the PIPL as China’s GDPR, the truth is that the PIPL introduces requirements that make it even more stringent than the GDPR. For example, the PIPL allows next of kin to exercise the rights of deceased persons, and it introduces personal liability for some violations. 

How Your Organization Can Achieve and Maintain Industry Compliance 

Organizations working with customer data must be aware of current privacy protection standards and frameworks in order to effectively achieve and maintain compliance. Here’s how. 

ISO 27701 Certification 

ISO 27701 is intended to help organizations protect and control the personally identifiable (PII) information that controllers and processors handle. This international standard streamlines compliance obligations by integrating privacy into an organization’s information security management system. 

Privacy Impact Assessments 

The E-Government Act of 2002 requires agencies to perform privacy impact assessments to evaluate systems that collect PII and determine whether the privacy of that PII is properly secured.  

Data Segmentation 

Data segmentation is the process of grouping data into two or more subsets based on use cases, types of information, and sensitivity of the data. Following segmentation, organizations can create security parameters and authentication rules to limit access to the data to only authorized personnel. For example, covered entities (as defined by HIPAA) and their business associates can apply data segmentation to PHI. 

GDPR Gap Assessment 

Failure to comply with GDPR can result in penalties and significant fines. To help your organization best prepare for GDPR compliance, A-LIGN offers a GDPR Gap Assessment. During this assessment, our auditors review your organization’s current data protection and privacy environment and provide a detailed gap assessment to help your organization achieve compliance.  

Consumer and Market Driven Actions 

Organizations are tasked with responding to changes in the data protection landscape driven by consumer advocates and market forces in a timely (and visible) manner. 

Apple Leads with iOS Privacy Changes 

Last year, Apple’s update to its iPhone operating system gave users the ability to opt out of data harvesters’ ability to track them across the apps they use on their phone. It was a blow to Facebook’s parent company, Meta. The tech company relies heavily on ad targeting and lost $10 billion last year as a result of users opting out, and expects to lose $10 billion more this year. Clearly, consumers want more privacy controls, which explains why Google is following Apple’s lead. The Android operating system maker is giving app developers two years to prepare for the new privacy restrictions. 

Data cooperatives  

Data cooperative refers to the voluntary collaborative pooling of personal data for the benefit of the group or community. After all, why should trillion-dollar Big Data companies be the only ones to benefit from the wealth of information that Big Data provides? Data co-ops give communities of individuals control of their data and negotiating power when it comes to monetization. It also drives common insights for the benefit of the community, such as data about community public health that can be used to address disparities in how healthcare (i.e., vaccines, testing, etc.) is distributed. 

Taking Steps to Achieve Compliance 

Data privacy continues to drive conversations and even the actions of consumers, and governments are responding to calls for regulating how personal data is collected and used.  

Compliance with data protection laws is mandatory, and failure to adhere to evolving legislation will lead to lawsuits and fines. In fact, last year, 27 privacy bills were proposed protecting PII. It will require constant vigilance to stay compliant with all the news laws that emerge. 

A-LIGN can help your organization adhere to regulations and affirm to clients that you take data privacy seriously. As a leading global cybersecurity and compliance firm, we are the industry’s trusted one-stop compliance for all cybersecurity and privacy needs. In addition to offering ISO 27001 + ISO 27701 certification, our services include data protection analysis which can determine whether your organization complies with government regulations including GDPR, CCPA/CPRA, and HIPAA.