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

/in , /by

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. The type and number of questions vary by SAQ type: the simplest SAQ has a couple of dozen questions and the most complex has almost 400. The right PCI SAQ for your company depends on how you process and handle cardholder data.

SAQ A

PCI SAQ A is for companies that have fully outsourced cardholder data processing to a third party. These include ecommerce stores, phone sales, and mail order companies. SAQ A can only be used if a company does not store, process, or transmit cardholder data on its systems or premises.

SAQ A-EP

SAQ A EP is exclusive to ecommerce retailers who (i) only sell via ecommerce; (ii) outsource credit card sales to a third party, but (iii) handle the delivery of cardholder data to payment processors. The ecommerce business does not store, process, or transmit cardholder data on their systems.

SAQ A-EP is superficially similar to SAQ A — both apply to ecommerce businesses that outsource the payment process. The critical difference is in the flow of cardholder data from the merchant to the payment processor and who collects that data.

SAQ A may be appropriate if cardholder data is collected by the payment processor. For example, your site redirects customers to a page on the payment provider’s site to enter information or displays the provider’s page in an iframe. In contrast, SAQ A-EP may be appropriate if your store collects cardholder data with an on-site form and then sends it to the payment processor via JavaScript code or some other means.

SAQ B

SAQ B is for merchants who use imprint machines or terminals to collect credit card data. The merchant does not store or process cardholder data. SAQ B is not relevant to ecommerce and most other credit card transactions that are carried out exclusively over the web.

SAQ B-IP

SAQ B-IP is a variation on SAQ B that applies to merchants who use PTS-approved terminals with an IP connection to the payment provider. SAQ B-IP does not apply to most businesses who transact electronically over the web.

SAQ C

PCI SAQ C is relevant for merchants that deal with card-not-present credit card payments over the phone or mail and card-present payments via point-of-sales terminals. The merchant does not store cardholder data electronically, but may have paper records. It is not relevant to ecommerce businesses.

SAC C only applies if your business does not store cardholder data electronically, but delivers it to a payment processor via a payment application system and internet connection on the same device or LAN, which are not connected to other systems within your environment.

SAQ C-VT

SAQ C-VT is for merchants who use virtual payment terminals on a device which is only used for credit card processing. It is not relevant to ecommerce and most online sales.

SAQ P2PE

PCI SAQ P2PE is for merchants who collect cardholder data via a hardware payment terminal with a PCI SSC-approved peer-to-peer encryption (P2PE) solution. SAQ P2PE is a relatively short questionnaire because cardholder data is encrypted as soon as it’s entered into the payment terminal—the merchant cannot decrypt it and has no access to the data. Only the payment processor has the encryption key.

SAQ D

PCI SAQ D is a catch-all SAQ for organizations that are eligible but do not meet the criteria we’ve outlined for the other PCI Self-Assessment Questionnaires. For example, they may not outsource credit card processing and they may store card data electronically. There are two versions of SAQ D: SAQ D for Merchants and SAQ D for Service providers. SAQ D is by far the longest and most onerous PCI SAQ, with over 320 questions.

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.

Learn more about PCI DSS from these KirkpatrickPrice resources:

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

/in , /by

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

/in , /by

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:

  FISMA FedRAMP
Who Needs It All government agencies, departments, and vendors Cloud service providers that host and protect government data
Who Can Perform the Audit Any third party security assessor A certified Third Party Assessment Organization (3PAO)
Number of Controls in Each of the Three Compliance Levels Low: 124

Medium: 261

High: 343

 Low: 125

Medium: 326

High: 421
Authorization Process Annual 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

ISO 27001 Certification vs. ISO 27001 Audit: What’s the Difference?

/in , /by

Do you want to demonstrate your commitment to security to global business partners? An ISO 27001 report provides organizations with an evolving ISMS that can adapt to new challenges and validates your commitment to security. It can also help you prioritize your information security budget and resources based on risk, because ISO 27001 is customized for your environment and your specific risks. Undergoing an ISO 27001 audit is also a way to be proactive in your information security and compliance efforts, which could be just what you need to stay ahead in your industry. So, what does the ISO 27001 certification process look like and who can perform an ISO 27001 audit? What’s the difference between ISO 27001 certification and an ISO 27001 audit?

The ISO 27001 Certification Process

In order for your organization to become ISO 27001 certified, there are a few steps you’ll have to take. To get the ISO 27001 certification process started, we suggest undergoing a gap analysis to identify any potential vulnerabilities. From there, you’ll remediate the findings and then begin the audit, which is comprised of two stages.

Stage 1 Audit

During your Stage 1 audit, or the “Documentation Review” audit, an external auditor will review your organization’s prepared ISMS documentation to ensure that is compliant with the ISO 27001 requirements.

Stage 2 Audit

Once you’ve completed the Stage 1 audit, your external auditor will evaluate the fairness and suitability of your information security management, controls, and practices. If your external auditor deems your organization’s ISMS compliant with the ISO 27001 requirements, they will recommend you for certification. ISO 27001 certification is a separate process involved a certifying body.

Value of an ISO 27001 Audit Without Certification

Did you know that many organizations opt to undergo the ISO 27001 audit and not pursue certification? It’s true. You might now be wondering, “Why would you pursue an audit and not want to get the certification?” The bottom line is because certification is not required. Instead, if you decide to pursue an ISO 27001 audit without certification, you will still receive an ISO 27001 report to offer clients and stakeholders who need assurance of your ISMS’ effectiveness, and you only need to work with one firm for your ISO 27001 needs.

Who Can Perform ISO 27001 Audits?

While both internal and external auditors can use the ISO 27001 framework to perform the Stage 1 audit and assess an organization’s ability to meet their information security requirements, using an external auditor is always wise. Here’s why.

When you pursue an ISO 27001 certification, best practice is to hire one firm to perform the audit and a separate firm for the certification process. This process may seem tedious, but it instills independence so that conflict of interest is never a concern.

KirkpatrickPrice only offers ISO 27001 audits and consulting. Our firm is not a certifying body, so any quotes on our ISO 27001 services will never include certification. If you are considering working with a firm that offers both auditing and certification services or has a partnership with another organization in order to offer both, this is a red flag. It indicates a lack of integrity and a conflict of interest, which could have negative implications on your audit and certification.

Have questions getting started on your ISO 27001 audit journey? Contact us today, and we’ll get you started.

More ISO 27001 Resources

ISO 27001 FAQs: Information Security Management for Your Organization

Choosing Between SOC 2 and ISO 27001 Audits

Was the Gap Worth It?

3 FISMA Compliance Levels: Low, Moderate, High

/in , /by

What is FISMA?

The Federal Information Security Management Act (FISMA) is a piece of United States legislation, enacted as part of the Electronic Government Act of 2002. FISMA’s intent is to protect government information and assets from unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems. FISMA is the law; NIST Special Publication 800-53, Security Controls for Federal Information Systems and Organizations, is the standard that contains the individual security controls required to comply with FISMA.

In addition to this, NIST developed FIPS Publication 199, which explains the standards for categorizing information and information systems to comply with FISMA. According to FIPS 199, information and information systems are defined by three security objectives: confidentiality, integrity, and availability. Should there be a loss of confidentiality, integrity, and availability, organizations must determine the potential impact according to the three FISMA compliance levels: low impact, moderate impact, and high impact.

3 FISMA Compliance Levels

To decide which of the three FISMA compliance levels applies to your organization, you’ll need to determine whether the potential impact to your organization would be limited, serious, or severe. NIST defines the three levels FISMA compliance levels as low impact, moderate impact, and high impact.

Low Impact

Low impact indicates that the loss of confidentiality, integrity, or availability is expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. Examples of low impact incidents include:

  • A breach that causes a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced
  • A breach that results in minor damage to organizational assets
  • A breach that results in minor financial loss
  • A breach that results in minor harm to individuals

Moderate Impact

Moderate impact indicates that the loss of confidentiality, integrity, or availability is expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. Examples of incidents with moderate impact include:

  • A breach that causes a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced
  • A breach that results in significant damage to organizational assets
  • A breach that results in significant financial loss
  • A breach that results in significant harm to individuals

High Impact

High impact indicates the loss of confidentiality, integrity, or availability is expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. Examples include:

  • A breach that causes a severe degradation in mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions
  • A breach that results in major damage to organizational assets
  • A breach that results in major financial loss
  • A breach that results in severe or catastrophic harm to individuals, involving loss of life or serious life-threatening injuries

Achieving FISMA Compliance

Determining which of the three FISMA compliance levels applies to your organization is the first step on your FISMA compliance journey. Once you determine your impact level as either low, moderate, or high, you can move on to deriving the information system impacted level in accordance with FIPS 200, and then finally, apply the appropriately tailored set of baseline security controls in NIST SP 800-53. This allows organizations to tailor the relevant security control baseline so that it more closely aligns with their mission and business requirements and environments of operation. Certification is achieved when an Authorization to Operate (ATO) is signed by a federal agency’s senior management official.

At KirkpatrickPrice, our senior-level experts can walk you through your FISMA compliance journey. If you’re eager to get started on your FISMA audit or if it’s just something on your radar, let KirkpatrickPrice help you get started. Contact us today.

More FISMA Resources

What Type of Compliance is Right for You? 10 Common Information Security Frameworks

Security Awareness Training Requirements: SOC 2, PCI, FISMA, and More