PCI DSS Compliance: What Do SAQ, AoC, and RoC Mean?

The Payment Card Industry Data Security Standard, or PCI DSS, was established as a standard security requirement for all entities that store, process, or transmit cardholder data. PCI DSS compliance helps to demonstrate your security commitment and assure your clients that their cardholder data is protected. When you engage in a PCI DSS audit, you’re testing your organization’s systems and processes against 12 technical and operational requirements made up of nearly 400 individual controls established by the PCI Security Standards Council to protect cardholder data.

There are three parts to a PCI DSS audit and the merchant level of your organization plays a part in determining what you need from a PCI DSS audit. Let’s take a look at the distinctions between a PCI DSS Self-Assessment Questionnaire (SAQ), Attestation of Compliance (AoC), and Report on Compliance (RoC).

What is a PCI SAQ?

The PCI Self-Assessment Questionnaire is a tool used to document an organization’s self-assessment of their security practices concerning cardholder data. There are nine different SAQ types which apply variably to different organizations depending on how they process, handle, and store cardholder data, including:

  1. SAQ A
  2. SAQ A-EP
  3. SAQ B
  4. SAQ B-IP
  5. SAQ C-VT
  6. SAQ C
  7. SAQ P2PE-HW
  8. SAQ D for Merchants
  9. SAQ D for Service Providers

These questionnaires help to determine which PCI DSS compliance requirements apply to your organization and how your current systems align with those security requirements. Although each of the SAQ types have different goals, your organization can evaluate which applies best to you so that you can obtain an AoC.

At KirkpatrickPrice, we offer guidance to help your organization work through your SAQ and ensure all of your yes/no answers are accurate according to your security systems. Even with a self-assessment, you’re not alone!

What is a PCI AoC?

The PCI Attestation of Compliance (AoC) is just that, an attestation completed by a Qualified Security Assessor (QSA) that states an organization’s PCI DSS compliance status. An AoC is documented evidence that an organization has upheld security best practices to protect cardholder data. Basically, an AoC is a written representation that your organization has completed the applicable SAQ and been verified by a QSA.

If your organization is a merchant, the requirements for a SAQ, AoC, and RoC vary depending on your PCI level of compliance. We’ve written an introduction on the 4 PCI merchant levels for you to refer to when determining your own level of compliance. Similarly to the SAQ, there are different versions of the AoC which coincide with the versioning for the SAQ. Whichever version of the SAQ your organization completes, the same version can be determined useful for your AoC.

What is a PCI RoC?

A PCI Report on Compliance (RoC) is issued by a QSA and details an organization’s security posture, environment, systems, and protection of cardholder data. The RoC is developed through a thorough assessment completed by a QSA that includes an onsite audit and review of controls. After an auditor tests your controls and obtains documentation of your processes, a summary of findings is developed which culminates in a final RoC.

Every RoC is organized according to the PCI Security Standards Council’s specifications for a qualified RoC which is derived from the RoC Reporting Template provided to all QSAs. The standardization of reporting allows your organization to provide every stakeholder, client, or interested party with a clear representation of your status on PCI compliance.

If you’re overwhelmed or confused by the PCI audit process, KirkpatrickPrice experts are here to help! Whatever your PCI objectives are, we want to partner with you to help you achieve your compliance goals. Call us today  to talk with an expert and start your PCI compliance journey.

Using NIST 800-53 vs. NIST 800-171 in a FISMA Audit

When any organization engages in a FISMA audit, their information systems are organized according to FIPS 199 and FIPS 200 to determine security categories and impact levels. Then, those systems are tested against a tailored set of baseline security controls. Depending on whether an organization is a federal agency or a private sector entity, different NIST publications of security controls may apply to the FISMA audit. How can you determine whether your organization should use NIST SP 800-53 or NIST SP 800-171 security controls? Let’s dive into what applies to your organization and what doesn’t.

What is a FISMA Compliance Audit?

First, what is the Federal Information Security Management Act, or FISMA, and what does a FISMA audit accomplish? FISMA is United States legislation intended to protect the security, confidentiality, and integrity of government data systems. A FISMA audit is a test of an organization’s system against the controls outlined in various NIST publications such as NIST SP 800-53, NIST SP 800-171, FIPS 199, and FIPS 200.

FISMA was developed to protect against unauthorized access, use, disclosure, disruption, modification, or destruction of government information and assets. When you choose to engage in a FISMA audit, you can expect to receive a report on their controls which can then be used to certify your organization when an Authorization to Operate (ATO) is signed by a federal agency.

NIST SP 800-53 in a FISMA Audit

NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, is the guideline established for federal agencies to uphold regulatory requirements regarding the management of their information security systems. Federal agencies categorize their security systems according to the NIST compliance levels: low, moderate, and high. NIST SP 800-53 security controls are classified into 18 control families, which help federal agencies determine the organizational impact and risk of their systems:

  1. Access Control
  2. Audit and Accountability
  3. Awareness and Training
  4. Configuration Management
  5. Contingency Planning
  6. Identification and Authentication
  7. Incident Response
  8. Maintenance
  9. Media Protection
  10. Personnel Security
  11. Physical and Environmental Protection
  12. Planning
  13. Program Management
  14. Risk Assessment
  15. Security Assessment and Authorization
  16. System and Communications Protection
  17. System and Information Integrity
  18. System and Services Acquisition

When you engage in a FISMA audit with NIST SP 800-53 controls, you are testing your information security systems against compliance standards for federal agencies in an effort to better your information security and risk management practices.

NIST SP 800-171 in a FISMA Audit

While federal agencies test their systems against NIST SP 800-53 controls, non-federal agencies that work with government entities can comply with FISMA by testing their systems against NIST SP 800-171 security controls. Controlled Unclassified Information, or CUI, is governed by NIST SP 800-171, so any organization handling CUI should use the NIST SP 800-171 standard to ensure their security systems are measuring up to security guidelines. The goal of NIST SP 800-171 is to protect unclassified information that isn’t considered part of federal information systems against unauthorized access, harm, or mishandling. NIST SP 800-171 controls are also categorized into families, but only in 14 categories:

  1. Access Control
  2. Audit and Accountability
  3. Awareness and Training
  4. Configuration Management
  5. Identification and Authentication
  6. Incident Response
  7. Maintenance
  8. Media Protection
  9. Personnel Security
  10. Physical Protection
  11. Risk Assessment
  12. Security Assessment
  13. System and Communications Protection
  14. System and Information Integrity

If your organization handles CUI, engaging in a FISMA audit with NIST 800-171 controls can benefit your information systems, the categorization of your security practices, and opportunities for your organization to conduct businesses with federal agencies.

At KirkpatrickPrice, we mold our audit process to fit your needs, whether that includes testing against NIST 800-53 controls or NIST 800-171 controls in a FISMA audit. With KirkpatrickPrice as your audit partner, you can get help from start to finish to determine what security testing will benefit your compliance goals. Contact us, today, to get help with your FISMA audit process!

More FISMA Compliance Resources

FISMA vs. FedRAMP

FISMA and FedRAMP audits are often confused because both involve compliance around government data. But, when you dive into the details of each audit, you’ll recognize the differences are stark. Let’s talk through each of these compliance audits and how you can tell them apart from one another.

What is FISMA?

The Federal Information Security Modernization Act, or FISMA, is U.S. legislation that requires government agencies to meet a standard of processes and system controls that protects the confidentiality, integrity, and availability of their systems. The implementation of these processes must align with the NIST standards such as NIST SP 800-53, NIST SP 800-171,  FIPS 199, and FIPS 200. All government agencies and their contractors are required to implement an information security program that complies with these established NIST standards under FISMA.

What is FedRAMP?

The Federal Risk and Authorization Management Program, or FedRAMP, standardizes the security practices of cloud solutions to comply with information security best practices. The goal of this audit is to provide a standard that cloud service providers (rather than government agencies) can check against to ensure their security practices measure up to governmental security needs. Continuous monitoring and automation are a focus of FedRAMP in an effort to increase cloud security and protection of government data for cloud service providers.

Comparing FISMA and FedRAMP

When you’re deciding which framework best fits your organization, it’s easy to get lost in the security talk. To help you determine whether you should engage in a FISMA or FedRAMP audit, we put together the most important differences between the two audits:

 FISMAFedRAMP
Who Needs ItAll government agencies, departments, and vendorsCloud service providers that host and protect government data
Who Can Perform the AuditAny third party security assessorA certified Third Party Assessment Organization (3PAO)
Number of Controls in Each of the Three Compliance LevelsLow: 124

Medium: 261

High: 343

Low: 125

Medium: 326

High: 421

Authorization ProcessAnnual reviews of reporting and current information security program“Do Once, Use Many Times” authorization by the government which is then reviewed by agencies

If you’re a cloud service provider focused on compliance for protecting government data, there’s a chance you’d benefit from both a FISMA and FedRAMP audit. Upon receiving a FISMA or FedRAMP certification, cloud service providers must obtain and maintain an Authority to Operate, or ATO, from a federal agency. Both FISMA and FedRAMP have different ATO variations – JAB P-ATO and FedRAMP ATO – which are required by federal agencies to engage in business with vendors.

These differences and complexities can seem overwhelming, but they don’t have to stop you from starting your compliance journey. At KirkpatrickPrice, we partner with you to ensure the scope of your engagement and audit framework align with your compliance goals. Contact us, today, to learn more about FISMA or FedRAMP and how we can help you start your audit journey.

More FISMA Compliance Resources

Learning from Twitter’s Privacy Mistakes

Because of the ever-changing landscape of privacy laws, standards, and guidelines, it has become difficult for businesses to know what their obligations are, and even harder to determine what could constitute non-compliance. Fortunately, Twitter’s mistakes now provide us with an example of what a violation looks like. Twitter has been in the spotlight for a recent hack, and now the Federal Trade Commission is investigating its privacy practices regarding targeted ads.

What Led to the FTC’s Investigation at Twitter?

In October 2019, Twitter admitted to using personal data obtained for security reasons for targeted ads purposes. The company stated, “We recently discovered that when you provided an email address or phone number for safety or security purposes (for example, two-factor authentication) this data may have inadvertently been used for advertising purposes, specifically in our Tailored Audiences and Partner Audiences advertising system.”

We now know, through Twitter’s SEC filing, that the FTC began its investigation after this announcement and Twitter received a complaint on July 28, 2020. Twitter faces a fine of up to $250 million for the violation.

3 Takeaways from Twitter’s Privacy Choices

We asked our privacy experts to comment on the FTC’s investigation and they found three key takeaways for businesses looking to avoid privacy mistakes.

  1. Qualified, third-party verification of privacy practices is critical because almost every organization believes they are using personal data appropriately. Twitter does not admit to intentionally misusing personal data (i.e. using the data for a purpose other than what the data was originally collected for). Twitter says the use of the personal data collected for security purposes in advertising was “inadvertent.” This is why privacy auditing is so important. An auditor can help you verify that your business is not misusing personal data and provide that assurance as a third party.
  2. There are legal and compliant ways to use existing personal data for new purposes. Twitter could have addressed this issue by getting a second level of consent, prior to using the personal data in ads, by asking users for permission to use the personal data obtained for security purposes in targeted advertising. If you’re a Twitter user, you may have been asked about this on your account recently, because the platform is now obtaining that second level of consent – but it’s too little too late for Twitter.
  3. Voluntary privacy commitments are just as significant as legal requirements. Twitter is in the hot seat because they broke their own promise that they make in their privacy commitments, not because they broke a law. You may not even be aware of it, but your business could be at risk for privacy sanctions even if there isn’t a specific law that applies to the collection and use of personal data for your industry, clients, or location. If an organization makes a promise regarding the use of personal data and breaks that promise, the FTC can fine them.

8 Elements of Privacy

As you navigate the privacy practices and obligations of your business, it is crucial to follow the industry best practices that already exist. This will empower your organization to develop appropriate processes for collection and use of personal data that are adaptable to new laws, regulation, and enforcement activity. We recommend reviewing and following the eight privacy criteria under SOC 2, stipulated by the AICPA, which are organized as follows:

  1. Notice and Communication of Objectives
  2. Choice and Consent
  3. Collection
  4. Use, Retention, and Disposal
  5. Access
  6. Disclosure and Notification
  7. Quality
  8. Monitoring and Enforcement

Could your organization unintentionally fail to meet any of these eight criteria? Twitter’s issues stem from failing to provide proper notice and communication of its objectives related to privacy, failure to obtain consent for the use of personal data for targeted advertising, improper use of personal data collected for security purposes, and potentially failing to perform proper monitoring.

At KirkpatrickPrice, we want to help your organization navigate your privacy obligations and enhance your privacy practices. We have a built a team of privacy experts to perform assessments, and they are watching enforcement trends, state laws, and federal legislation closely to ensure that you protect the personal data you are responsible for. Let’s talk today!

What’s Going On With the EU-US Privacy Shield Agreement?

The Latest With Privacy Shield

On July 16, the Court of Justice for the European Union made a landmark decision to invalidate the EU-US Privacy Shield arrangement for international data transfers. Prior to this announcement, Privacy Shield was one of several mechanisms for meeting GDPR data protection requirements for data leaving the EU for the US. The Court’s decision impacts the thousands of organizations participating in and relying on Privacy Shield to facilitate international commerce.

Privacy advocates and the Court’s real contention was not with Privacy Shield itself, but with the nature of US federal surveillance abilities and practices. The Court’s statement explains, “In the view of the Court, the limitations on the protection of personal data arising from the domestic law of the United States on the access and use by US public authorities of such data transferred from the EU to that third country…not circumscribed in a way that satisfies requirements that are essentially equivalent to those required under EU law, by the principle of proportionality, in so far as the surveillance programmes based on those provisions are not limited to what is strictly necessary.”

How Does This Impact Your Business Today?

First, data transfers between the EU and the US will still be permitted, but the invalidation of the EU-US Privacy Shield agreement will require US businesses receiving EU data to find an alternative compliance solution. Specifically, US organizations will need to use either the standard contract clauses or binding corporate rules to satisfy GDPR’s international data transfer requirements.

Second, just because Privacy Shield no longer satisfies GDPR does not mean that you can stop following Privacy Shield requirements. The Federal Trade Commission commented, “We continue to expect companies to comply with their ongoing obligations with respect to transfers made under the Privacy Shield Framework. We also encourage companies to continue to follow robust privacy principles, such as those underlying the Privacy Shield Framework, and to review their privacy policies to ensure they describe their privacy practices accurately, including with regard to international data transfers.”

Third, now is the time to review your contracts and requirements of your processors or sub-processors. What is their plan to replace Privacy Shield? How will their plan impact you?

What Will Happen to EU-US Data Transfers in the Future?

The bottom line is that we are operating in a period of uncertainty. Fortunately, we now have a baseline for privacy best practices, but it gets complex when then there are specific regulations and requirements for your business. That is why it’s crucial for your organization to continue to meet the baseline, but also assign responsibility to someone internally to monitor new developments.

In the future, the US may create a Privacy Shield replacement. U.S. Secretary of Commerce Wilbur Ross stated, “While the Department of Commerce is deeply disappointed that the court appears to have invalidated the European Commission’s adequacy decision underlying the EU-US Privacy Shield, we are still studying the decision to fully understand its practical impacts. We have been and will remain in close contact with the European Commission and European Data Protection Board on this matter and hope to be able to limit the negative consequences to the $7.1 trillion transatlantic economic relationship that is so vital to our respective citizens, companies, and governments. Data flows are essential not just to tech companies—but to businesses of all sizes in every sector.”

KirkpatrickPrice’s team of privacy experts will be closely watching new developments with Privacy Shield and other data privacy regulations. If you have concerns or questions about this update’s implication for your business or if you need GDPR compliance solutions, let’s talk.

More Privacy Resources

CCPA Roadmap for Compliance

How to Write a Privacy Policy

Trends in Privacy, Breach Notification, and Data Security Legislation