A-LIGN’s Compliance Crosswalk podcast features discussions at the intersection of security, privacy, compliance, and risk management. On our fourth episode, hosts Blaise Wabo, Healthcare and Financial Services Knowledge Leader, Arti Lalwani, Risk Management and Privacy Knowledge Leader, and Patrick Sullivan, Vice President of Customer Success, share their thoughts and insights on A-LIGN’s 2022 Compliance Benchmark Report.   

What is the 2022 Compliance Benchmark Report? 

Our 2022 Compliance Benchmark Report offers insights into how your organization’s cybersecurity and compliance efforts stack up against other organizations across various industries.  

We surveyed more than 700 cybersecurity, IT, quality assurance, internal audit,  

finance, and other professionals about their compliance programs with the goal of gaining a better understanding of their organization’s position when it comes to compliance, including strengths, weaknesses, and opportunities. 

What’s Changed in the 2022 Report? 

There are common themes between the 2021 and 2022 Benchmark reports, including the fact that cybersecurity and compliance remain a top priority for organization’s across industries. Compliance is still a driver for winning new business and maintaining relationships with existing customers. Therefore, obtaining (and maintaining) certain certifications is still a major motivator for growing organizations.   

However, there are noticeable differences between the reports as well. In 2021, 25% of those surveyed were using some sort of compliance software to either drive or to complete compliance assessments. But in 2022, we see close to 75% of organizations utilizing compliance software and platforms. 

Patrick Sullivan speculates that this big jump can be attributed to organizations recognizing how important cybersecurity is and how urgently they need to act on minimizing threat levels. Even with the Great Resignation forcing personnel shifts, many organizations still devoted more of their resources to developing stronger business continuity plans to prepare for disasters or security incidents.  

The Rise of Audit Fatigue 

With so many third-party assessments offered and frameworks and regulations to follow, the experts at A-LIGN caution compliance experts to avoid “audit fatigue.”  

Too many organizations view audits as a catch-all, building strategies around the audits they complete instead of the other way around. Before registering for assessments, organizations should take a step back and look at their compliance and security frameworks as a whole. Build a compliance strategy first, then pursue audits that meet the needs of that strategy. 

“It’s possible to solve all of your problems but not have the solution you want,” Patrick explains, which is why organizations should determine what frameworks they actually need to follow before proactively pursuing them.  

Cybersecurity Concerns in 2023  

It’s not too early to start making predictions about which trends will become more prominent in the next year.  

The 2022 Benchmark Report found the Health Insurance Portability and Accountability Act of 1996 (HIPAA) to be one of the top three compliance services organizations are looking to lean more into in the following year.  

HIPAA’s rise in popularity is a sign of the times. Following the height of the COVID-19 pandemic in 2020, the telehealth market saw a rapid rise in popularity. Organizations expanded services and brought on many third-party vendors, which unfortunately surfaced vulnerabilities and led to an increase in healthcare-related cyberthreats. 

Blaise notes the value of healthcare data as a major driver for targeted attacks. He speculates that most of the hackers nowadays are not just looking for the money but are also looking for data that has real value—and there’s no better way to do that than infiltrating healthcare systems. In fact, the value of one health record on the black market is anywhere from $650 to $2,000 per record. 

Beyond the healthcare industry, ransomware attacks are poised to become a more commonplace issue into 2023 and beyond. We’re predicting a rise in Ransomware as a Service — a practice where bad actors package ransomware into a kit. They can then sell this kit to a less sophisticated bad actor, granting that entity access to all of the tools needed to attack an organization’s network.  

How Organizations can Start Preparing Now   

While it’s hard to predict what exactly the future holds, perhaps the most important thing organizations can do is find a trusted partner to help address their cybersecurity concerns.  

“Finding a trusted partner is definitely key,” says Blaise. Both compliance and cybersecurity require certain protocols for certain types of information, and for some, this can be a sensitive topic to broach. People should feel comfortable discussing their organization’s weak points with their security provider, and establishing a strong relationship before a cyberattack occurs. 

Join Blaise Wabo and Arti Lalwani for episode five of the Compliance Crosswalk podcast, available in July.

As security tools get more innovative, so do the threat actors aiming to compromise your systems.  

Many of these bad actors have taken to recycling existing malware variants, even if it’s only making minor tweaks to make the attacks slightly different. Cybercriminals aren’t always reinventing the wheel — but it only takes the smallest of changes for a once-preventable variant to suddenly slide past your systems undetected.  

It’s important for organizations to take a proactive approach to their cybersecurity. Preventative measures like penetration tests can determine how IT systems would hold up in a real-world attack scenario, which is quite valuable given the current global threat environment. 

What Is a Penetration Test?  

Penetration tests (pen tests) are simulated cyberattacks designed to assess the cybersecurity of your organizational technologies and systems. Composed of multiple steps, this process:  

• Tests your organization’s information security of both technologies and systems   
• Identifies vulnerabilities in your cybersecurity posture before threat actors do  
• Helps your organization remediate security and compliance gaps  

Pen tests are performed by ethical hackers, meaning the tests involve carrying out attacks on real systems and data using the same tools and techniques an actual attacker would. However, the information collected is not sold to malicious third-party groups, and the organization is not placed in actual danger.  

Why a Pen Test Is Needed 

As data breaches continue to dramatically increase in both depth and complexity, organizations have bolstered their lines of technological defense. But with the numerous variants of malware comes the possibility of a security incident.   

A penetration test is the best way to see if a threat actor can take advantage of any exploitable vulnerabilities. These new malware variants attempt to evade detection from common vulnerability scans. While the variants fail the majority of the time, this might not always be the case.  

With 560,000 new pieces of malware  being detected every day and four companies falling victim to ransomware attacks every minute, it is easy to see how a variant can slip through the cracks. Pen testing is a good way to ensure your incident response team can minimize the amount of damage done.  

A penetration test is a good way to test an organization’s incident response team, as they can determine where lapses in protection hide without putting any sensitive information in harm’s way.  

When It Comes to Pen Testing, Focus on the Big Picture  

It is critical to know where all of the weaknesses lie in an organization’s tech stack.  

However, some may only associate these fragile points with already-discovered vulnerabilities. Organizations need to look at the bigger picture when examining their defense systems and determining risk.  

System vulnerabilities can show a lack of process, a lack of knowledge, and a lack of planning within an organization.  

For example, a penetration test can reveal deficiencies related to how a company keeps its servers updated or how they apply patches. It can also show everything from a lack of logging and monitoring to the lapses of protection if an event were to happen.  

This is why it’s so important to start with a solid security framework — such as one from NIST — when deploying a network. This makes it easier to establish strong cybersecurity controls while also helping to manage and reduce cybersecurity risk. 

As for the networks that have already deployed, you can compare its current state to already-existing frameworks to determine where gaps may hide. 

Pen Testing Can Play a Role in Preventing Cyberwarfare  

Even before the Russian/Ukrainian war, Ukrainian organizations have frequently found themselves victims of cyberattacks, from phishing campaigns to malware variants.  

Earlier this year, the country narrowly avoided a serious cyberattack on their nation’s power grid. Hackers used malicious software to target one of Ukraine’s largest energy companies, trying to shut down substations. If successful, this would have caused blackouts for two million people. 

Fortunately, cybersecurity companies were able to identify and neutralize the software before the attack could do any damage, but this isn’t always the case. 

Government-targeted cyberattacks are on the rise in the United States as well. In 2020, 68% of states saw at least one of their municipalities fall victim to attack, many of them instigated by nation state actors. 

Routine pen tests (at minimum once a year) can reassure both governments and private organizations that their current safety protocols are up to date. But, for real-world protection, conducting pen tests more often will help to better protect your organization.  

Become More Proactive About You Cybersecurity Today 

When it comes to keeping your networks secure, it’s not a matter of if a cyberattack will occur, but when.  

There’s no way of predicting when these attacks will take place, but if a security incident should happen, it’s important to have already solidified how your organization will respond. Tools like pen testing can help teams create strategies to avoid a potential disaster.  

For an extra layer of protection, organizations should consider adding a vulnerability scan to their penetration tests as well. Vulnerability scans check an organization’s network and systems for any known vulnerabilities against a database of vulnerability information. Paired alongside pen tests, organizations can more effectively enhance their security posture by taking a truly proactive approach to cybersecurity. 

A-LIGN’s OSEE, OSCE, and OSCP Certified Penetration Testers will use the latest cybersecurity tactics to ensure your organization’s critical data is protected. 

Is your organization prepared to face a cyberattack? Our Ransomware Preparedness Assessment can help you find out.  

For many businesses, the biggest challenge in obtaining a HITRUST CSF certification is having to establish policies and procedures that satisfy the HITRUST criteria, which is a requirement for the r2 Assessment. Note that policies and procedures are still required in an i1 Assessment, but without the rigorousness of the r2 Assessment as described in this blog.

While organizations focus carefully on implementing each HITRUST control requirement, I also suggest they pay close attention to their policies and procedures. Prioritizing strong HITRUST policies and procedures is crucial to passing the audit and earning a HITRUST certification.

It’s also best to create and document policies and procedures for the HITRUST CSF sooner rather than later, as they must be in place for at least 60 days prior to the audit carried out by an external assessor.

Read on to learn more about HITRUST policies and procedures, the minimum requirements for documentation, and what to do if you don’t have sufficient resources to handle such an initiative.

Understanding HITRUST Policies and Procedures

A big reason why companies often treat HITRUST policies and procedures as an afterthought is that they have existing documentation mapped to another standard (such as SOC 2 or ISO 27001) and assume they can carry over to cover HITRUST requirements. This is not the case — in fact, most of the time, an organization will have to completely rewrite their policies and procedures in order to meet HITRUST requirements.

Here are the key points to know about HITRUST policies and procedures.

What are HITRUST policies?

HITRUST policies are the rules an organization and its employees must follow in order to achieve a specific goal. According to the most recent HITRUST Assurance Advisory (2021-014), “A documented policy must specify the mandatory nature of the control requirement in a written format which could reside in a document identified as a policy, standard, directive, handbook, etc.”

HITRUST policies should contain statements from management describing how your organization plans to adhere to each HITRUST control requirement. For example, “Acme Corporation will keep up a vulnerability management program that proactively identifies and detects information security vulnerabilities, so that the business may…” (ending with the goal the company aims to achieve through vulnerability management).

What are HITRUST procedures?

HITRUST procedures provide an explanation of the “how” behind HITRUST policy implementation by describing step-by-step instructions for specific routine tasks. As per the latest HITRUST Assurance Advisory, “A documented procedure must address the operational aspects of how to perform the requirement. The procedure should be at a sufficient level of detail to enable a knowledgeable and qualified individual to perform the requirement.”

• This means each of your procedures must give a detailed description of:
• How the policy is being implemented
• When each step of the procedure should be performed
• Who is performing specific actions related to the procedure
• Additional details on timing and accountability

HITRUST procedures should answer the “how,” and provide some details on “when,” and “who” where applicable behind each policy. For example, the official Vulnerability Management Procedure for Acme Corporation would provide a comprehensive account of its scope and goals, key responsibilities assigned to specific roles and departments, descriptions of various security assessments involved in the program, a schedule delineating the frequency of audits, and more.

What HITRUST Policies and Procedures Does My Organization Need to Document?

Because the HITRUST CSF is a flexible and scalable security framework that is tailored to the compliance needs of each organization, the exact policies and procedures required will depend on the scope of your assessment.

That being said, at a minimum you must have policies and procedures in place that address the 19 HITRUST control domains. Your organization must receive a maturity score of at least “3” (on a maturity level scale from 1-5) for each control domain in order to earn HITRUST r2 certification. Having strong policies and procedures in place and effectively implemented make up the baseline of HITRUST compliance. The HITRUST CSF control domains are:

• Information Protection Program
• Endpoint Protection
• Portable Media Security
• Mobile Device Security
• Wireless Security
• Configuration Management
• Vulnerability Management
• Network Protection
• Transmission Protection
• Password Management
• Access Control
• Audit Logging and Monitoring
• Education, Training, and Awareness
• Third-Party Assurance
• Incident Management
• Business Continuity and Disaster Recovery
• Risk Management
• Physical and Environmental Security
• Data Protection and Privacy

Again, to address the 19 HITRUST control domains, the information included in your documentation depends on the compliance needs of your business and the scope of your assessment. Scoping factors that determine your organization’s number of control requirements and therefore inform your policies and procedures include:

• Company industry
• Company size
• Company location
• Types of data handled
• Data access and usage (including third parties)
• How systems process, store, and transmit data

For example, a company with a HITRUST CSF assessment that covers 250 control requirements will have a different password management policy than a company with 450 control requirements. The latter organization may have a control that states employees must change their password every 90 days while the former organization may not have any such control.

Solving for a Resource Deficit When Designing HITRUST Policies and Procedures

After comprehending the structural nuances of the HITRUST CSF, it is very common for organizations to realize they simply don’t have the resources and/or budget required to create and document the necessary HITRUST policies and procedures from scratch.

If you are worried your organization does not have the proper resources in place — a trusted HITRUST advisor can help. Following a Readiness Assessment designed to pinpoint gaps in your organization’s environment, A-LIGN can provide comprehensive HITRUST Risk and Advisory Services that include any combination of:

• Creation of policies and procedures
• Documentation of policies and procedures
• Gap remediation for policies and procedures
• Implementation of nontechnical controls
• Gap remediation for nontechnical controls (e.g., develop an incident response plan or BCDR plan, help conduct HIPAA training, etc.)

Our practiced guidance will accelerate your path toward HITRUST certification, saving both time and resources. Read the story of our partnership with Sandata Technologies that inspired the company’s Security Director, Michael Alcide, to say, “[A-LIGN’s] guidance throughout the entire [HITRUST] process was invaluable. They helped us understand the small nuances and specific requirements that are always changing.”

Take the Stress Out of HITRUST

It’s no secret that achieving HITRUST certification can be complex and, at times, confusing. Leverage industry experts who are deeply familiar with HITRUST (500+ assessments with a 100% successful certification rate) and your organization will be more efficient with assessment preparation, including documentation of the necessary policies and procedures.

Looking to expedite your path to HITRUST certification?

Download our HITRUST checklist now!

Why is it important to assess the security of your vendors?  Because your organization is only as secure as your outside resources and it’s imperative to ensure your vendors are HITRUST certified.   

Regardless of if you just started your HITRUST journey or if you’ve been certified for years, you probably ask yourself the typical questions …  “What is our security posture?”, “what controls do we have in place?”, and “what controls do we need to implement, measure, and manage, to become compliant and maintain the HITRUST CSF Certification?”.    

What is one thing all these questions have in common?  An inward focus.  Although you’re right in the fact that these questions are important to answer, by focusing inward, you’re overlooking crucial areas that could put your organization at risk- those areas handled by external service providers and vendors.    

In 2015, many large corporations in the healthcare industry, including Anthem, Health Care Services Corporation (HCSC), Highmark, Humana, UnitedHealth Group, and many more, issued a requirement for all of their downstream vendors to achieve HITRUST certification.  The purpose of this requirement was to ensure the safe handling of all sensitive information. Fast forward six years, and it’s now an industry standard for all vendors, large or small, to offer a HITRUST CSF solution.    

Let’s take a look at why it’s so important to assess your vendor’s security posture. 

What is HITRUST CSF?    

The HITRUST CSF is a robust and scalable framework for managing regulatory compliance and risk management of organizations and their business associates. Originally designed specifically for the healthcare industry, the HITRUST framework has found success across multiple industries thanks to it unifying regulatory requirements and recognized frameworks including, but not limited to:   

• ISO 27001  
• NIST SP 800-53  
• HIPAA/HITECH   
• PCI DDS  

With its ability to combine several assessments and standards into one framework, the HITRUST CSF allows organizations to decide what regulatory factors they want to include in their assessment based on the level of risk and the regulatory requirements. This “assess once, report many” approach means that assessors are performing several different audits, but the organization feels like they’re only undergoing one – saving them time, money, and resources. Because of this benefit and its comprehensive focus on security and privacy, the HITRUST CSF has been widely praised and adopted by organizations around the world.  

If your organization works with outside vendors or partners, it’s important to ensure they take data security and privacy as seriously.  After earning your own HITRUST CSF certification, the next step is to assess your vendors.  

Why Assess Vendor Security?  

The HITRUST CSF Assessment methodology requires testing of all relevant controls for in-scope data, systems, and applications- even when they are owned and performed by a third-party. The controls can be directly tested as part of your assessment, explained in a formal security assessment, such as a SOC 2, or they can be ‘inherited’ from the vendor.   

What this means for a company seeking HITRUST certification is that all related controls must be satisfied for every location (including cloud service providers and software-as-a-service products) and every application in the solution.  Examples of related controls include the following:  

• Physical security for the datacenter where information is stored  
• Network security for the application that is used  
• Encryption of sensitive data  
• Monitoring for unauthorized access and devices  
• And more 

Cybersecurity compliance is advancing and it’s no longer good enough for you to have great security if your vendors do not.  Now that you’re ready to select your HITRUST-certified vendors, it’s important that you learn where they are in their HITRUST certification process.  Your vendors can provide you with a self-assessment, validated assessment or certified assessment.    

At the very least, it’s suggested they provide a validated assessment as it’s a more rigorous process due to independent testing of the controls performed by an authorized CSF external assessor firm.  Upon completion, HITRUST reviews the complete assessment and issues a Validated Report as the outcome if the organization has failed to receive a rating of 3 or higher on any of the controls.   When undergoing the validated assessment, any gaps in evidence or control performance affect their certification attempt and may disqualify them from your vendor selection process.  If you are unsure about whether your vendors and suppliers meet the necessary requirements, it’s important to have the tough conversations to learn what assessments have been performed, whether they will provide full reports for review, and whether they participate in the HITRUST inheritance program.  

How Can A-LIGN Help?  

A-LIGN’s Advisory Team will review your company’s policy and procedure documents and evaluate them against the HITRUST CSF.  We will share any gaps identified and will remediate those gaps by updating and documenting the policies and procedures accordingly to meet the HITRUST CSF specifications. If your company needs policies and procedures created, we can design and document those appropriately after performing interviews to understand the control environment. We can also assist in documenting non-technical controls such as Risk Assessment, Incident Response, Disaster Recovery, and more. 

Once all gaps are remediated, the A-LIGN Assurance team will perform an independent review and submit the assessment to HITRUST for certification. 

Our team of HITRUST experts are here to answer any question you might have through every step of the process by responding to all inquiries within 24 hours. With A-LIGN, you’re on the right path to HITRUST certification success.  

Interested in learning more about HITRUST CSF?  Complete a form and one of our cybersecurity and compliance professionals will reach out soon. 

Download our HITRUST checklist now!

ISO/IEC 27002 has not been updated since 2013, but that all changed when the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) published an update to the standard in February 2022 – ISO/IEC 27002:2022. So, what does this mean for organizations that look to the guidance standard for direction on how to configure their information security management system (ISMS) to achieve compliance? 

On Episode 2 of Compliance Crosswalk, hosts Arti Lalwani and Blaise Wabo sit down with guest Steve Holladay of Arrowhead Training to discuss the updated ISO 27002 and share insights on how the recent changes will impact listeners’ organizations.   

Making ISO 27002 Easier to Understand 

Steve Holladay has been in the standards industry for 40 years and is a consulting professional with Arrowhead Training – a company on a mission to demystify management system accreditation requirements through standards training. His decades of experience made him the perfect guest to discuss insights on the newly revised ISO 27002.  

To kick things off, the group explored the change in nomenclature from domain to themes. Through mergers and elimination of redundancies, the new ISO 27002 reduces the 114 controls formerly categorized by domains down to 93 controls, and groups them into four themes – Organizational controls, Technological controls, Physical controls, and People controls.  

Worth noting: None of the previous controls were actually eliminated, merely merged. In addition 11 new controls were added. Fortunately, the standard contains two annexes which users can use to trace the updated controls back with their corresponding former controls, and vice versa. 

In his view, Steve believes replacing domains with themes will assist the business leaders in better understanding their ISMS and how the controls help secure information. The challenge that many of those working in non-tech companies encountered with the 27002:2013 standard was understanding the definition of the domains. After all, they were written for IT professionals rather than management.  

By shifting to the concept of themes, stakeholders should better comprehend what the standard is trying to accomplish as it relates to their business or management system. Steve anticipates high acceptance of the standard as a result of this revision.  

And as a bit of advice, he recommends organizations don’t attempt to jam their current ISMS into the four new theme areas. Rather, they should redesign their ISMS from the ground up around the themes. While it will take some work, it will result in a more effective system.  

Designed for Present and Future Threats 

Threats to information security are always evolving, and so one of the 11 new controls added to ISO 27002 centers on “threat intelligence.” It’s a significant change that is especially relevant in the post-pandemic era where online activity and the danger of cybercrime remain elevated.  

According to Steve, there was previously a “one and done” mentality to risk assessment. “Once the risk assessment was done, organization’s really didn’t look at it again.” The new guidance frames threats as a danger that needs to be continuously evaluated with appropriate actions put into place to safeguard against them.  

Blaise praises the updated standard for its flexibility, particularly in this environment of increased ransomware attacks, and rapid cloud adoption which makes organizations more vulnerable to cyber crimes. ISO 27002 gives companies latitude to implement their own controls while meeting the objectives of the themes. “I think this is a win for the industry.” 

Arti stresses that an ISMS is a management system and was never meant to be a checkbox system that is reviewed  once a year. Positioning the risk assessment within an ISMS as a  living document will make things easier for everyone when it comes time for the annual audit.  

Time to Get Started 

Considering that ISO 27002 is a guidance standard, will the actual ISO 27001 standard be similarly updated? Most operators in the space might assume so, but Steve shared some inside knowledge: ISO 27001 will be amended sometime between now and October.  

This is good news for organizations currently in a holding pattern in anticipation of the change. Since the upcoming revision will be an amendment rather than an update, organizations can immediately start applying the 27002:2022 guidance standard to their ISMS to achieve compliance.  

“We want to encourage clients not to wait,” says Steve. “Go ahead and start exploring the standard. You’re way ahead of the game by looking at those controls and understanding how ISO 27002:2022 will fit within your organization.” 

Arti wholeheartedly agrees on getting a jump on things and recommends those currently undergoing their ISO 27001 audit to update their ISMS using the available ISO/IEC 27002:2022guidance. This way, an updated  SOA will reflect compliance with the new control set. 

A parting message: Reach out to your certification body (CB). The CB will let you know any available updates to your current ISO 27001 certificate. Purse an ISO 27001 certificate to ensure your ISMS is conforming with the  standard and confirm your controls are robust and effective to counter all threats – those present and those yet to come.  

Click here to watch the full video of this episode.

Click here to stream all episodes of the Compliance Crosswalk podcast.

Download our ISO 27001 checklist PDF!

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.