When a third-party auditor performs a PCI audit, it results in a PCI Report on Compliance (ROC). There are six control objectives with 12 subject areas. There are over 200 controls and 1,000 audit tests that make up the framework and process. All PCI audits are performed by a PCI Qualified Security Assessor (QSA). A PCI audit is an information security audit focused on the protection of credit card data. PCI DSS is a very robust information security standard, and is also sometimes used as a best practice, even without handling credit card data.
Additionally, if you have a client who is required to comply with PCI DSS, they are required to validate your compliance with the standard as well. If you store, transmit, or process cardholder data, you will be required to comply with PCI DSS. The PCI Data Security Standard applies primarily to the payment card industry. A third-party audit would provide validation of your controls and their appropriateness and effectiveness. There is no “hard list” of requirements for HIPAA, and there is no certification. You must begin by performing a Risk Assessment to determine what the appropriate physical, administrative, and technical safeguards are, implement those, and then perform regular monitoring to ensure the safeguards are still appropriate. Much like the SSAE 16, HIPAA compliance is risk-based. Legislation requires appropriate Physical, Administrative, and Technical Safeguards to protect PHI. Any entity who handles Protected Health Information (PHI) will be responsible for compliance with HIPAA. If you are working for a healthcare provider or a Business Associate who services a healthcare provider, you are going to be asked for validation of your compliance with HIPAA laws. The established criteria for each principle address the following questions: How are your policies and procedures relative to the standard documented? How do you communicate those to all interested parties? How do you monitor that those controls are being effectively performed? HIPAA
SOC 2 was specifically designed to report on one of five principles: Security, Availability, Confidentiality, Processing Integrity, and Privacy. The SOC 2 framework is finally gaining popularity. Whereas SOC 1 was designed to validate internal controls at a service provider that relate to client financial reporting and validate information security, SOC 2 was a framework specifically designed for companies delivering technology related services. Typically, the same clients who are asking you for an SSAE 16 will be the ones asking you for a SOC 2 audit.
An SSAE 16 audit is as good as its scope. A third-party auditor would be looking at your environment to make sure your objectives are appropriate, your controls are effectively designed, and that you are doing what you say you are doing. The SSAE 16 audit takes a risk-based approach, with specified objectives that are created to address client risk, and controls, or activities, to accomplish each objective. So what is an SSAE 16? It’s an audit and report on internal controls (whether related to information security, financial, operational, or compliance controls) at a service provider that are relevant to their client’s data. It is the most commonly used form of attestation for service providers in the US. Who asks for an SSAE 16? If you work with publicly traded companies, financial institutions, or state or local government, you will frequently be required to have an SSAE 16 (or SOC 1) audit performed by a third party. To help answer these questions and truly familiarize you with the different audit frameworks, we’ve broken down the Who’s, What’s, and Why’s for the most commonly reported on frameworks. Which one is right for me? Which one should I pursue? Why would I get this audit over that audit? As auditors, these are the questions we are most frequently asked. We’ve all heard of the Alphabet Soup, but what do they all really mean? SSAE 16, SOC 2, HIPAA, PCI DSS, FISMA, ISO 27001.
0 kommentar(er)
