IT Checklists for PCI Compliance

Detailed checklists for teams working on PCI compliance.


We created our PCI Guide to help businesses get compliant with PCI standards and avoid data breaches. While C-level executives and compliance officers may oversee a PCI compliance program at the highest levels, it’s the IT managers and teams who are tasked with the day-to-day details of what “compliance” really means.

That’s why we include PCI Guide IT checklists to go along with each PCI DSS requirement.

IT pros keep businesses running: they often manage networks, field support requests, give trainings, oversee deployments, and serve as database admins—all in the course of a day. Data security and compliance are added responsibilities on top of maintaining basic business operations, so separate and thorough tracking methods can help make the entire organization more secure. 

Download our PCI Compliance IT Checklists here.

Information technology team management


IT pros have told us that they love our PCI guides specifically for the checklists. They use them to PCI Report on Compliance (ROC) or prepare for a PCI audit. The lists provide a starting point and help keep teams and individuals on task.
manage everyday security tasks, as well as to fill out their

Some IT departments print off the checklists for every member of their team to make sure no one is missing anything.

SEE ALSO: The 12 Requirements of PCI DSS

Interactive PCI compliance checklists


There are twelve lists—one to cover each requirement—and within each are interactive fields and checklists. Managers and team members can enter to whom the requirement list is assigned, its assigned completion date, and actual completion date.

As interactive PDFs, the checklists can be checked and unchecked. So, teams can keep track of progress on the PDF versions, or just print them out and take them on the go. This feature also doubles as a way to easily document general PCI compliance efforts at your organization.

INFOGRAPHIC: 2017 Data Breaches

IT data security tasks


These lists are based specifically on PCI DSS requirements, and they are designed to help managers make sure that even the smallest tasks are covered. Each list includes subsets of “things you will need to have,” “things you will need to do,” and “things you may need to do.”

 We reference the specific PCI DSS requirement that goes with each task. For instance, on the checklist for “Requirement 4: Transmitting Cardholder Data,” we match up tasks with their specific requirement found in the PCI DSS: 4.2b, 4.1, 4.1.1, etc.

The SecurityMetrics Guide to PCI DSS Compliance


For even more information and tips about PCI DSS compliance, check out our PCI guide. Our 2018 version includes the interactive checklists as well as PCI auditor insights, forensic data breach statistics, and more in-depth information on each of the requirements.

SEE ALSO: Top 5 PCI Blog Posts for SMBs

The SecurityMetrics PCI Guide protects businesses


We help businesses avoid data breaches because for us, data security is personal. Our CEO Brad Caldwell founded SecurityMetrics in 2000, two years after a data breach at his small business left him without affordable options for remediation.

We create content like our PCI Guide and Checklists to help businesses protect themselves from hackers and cybercriminals who want to steal data or collect ransoms.

If you'd like to learn more about PCI compliance or are interested in a PCI audit or HIPAA audit, contact us here.
PCI 3.1: Stop Using SSL and Outdated TLS Immediately

PCI 3.1 SSL TLS

“SSL has been removed as an example of strong cryptography in the PCI DSS, and can no longer be used as a security control after June 30, 2016.”

Gary Glover, Director of Security Assessments
Gary Glover
SVP, Assessments
UPDATE: As of May 2017, PCI DSS 3.2.1 is the latest standard. Read more about the 3.2.1 updates.

June 30, 2018 is the deadline for merchants to disable SSL/early TLS and implement a more secure encryption protocol. TLS 1.1 or higher is required (TLS v1.2 strongly encouraged).


In April of 2015, the Payment Card Industry Security Standards Council (PCI SSC) released an unscheduled and important update: PCI DSS version 3.1. While it did include minor clarifications and additions, PCI 3.1 was primarily released to address the insecurity of Secure Sockets Layer (SSL) and some Transport Layer Security (TLS) encryption protocols.

After the release of PCI 3.1, all SSL and early TLS versions were not (and still are not) considered strong cryptography.

SSL and TLS encrypt the information sent between web browsers and web servers. Since the release of SSL v3, unfixable vulnerabilities were identified. You may have heard of some of these vulnerabilities back in 2014, including FREAK, POODLE, and WinShock.

The point is, the PCI Council has deemed that SSL and early TLS will no longer protect cardholder data.
PCI 3.1 SSL TLSSince the April 2015 update, merchants were not allowed to implement any new technology relying on SSL or early TLS (version 1.0 and sometimes 1.1, depending on use and implementation). Merchants already using systems and devices that utilize SSL and TLS must discontinue the use of those systems and devices before June 30, 2016.

The PCI DSS v3.1 requirements directly affected are:
  • Requirement 2.2.3 Implement additional security features for any required services, protocols, or daemons considered insecure.
  • Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.
  • Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

Each of these requirements will have additional sub-requirements or guidance provided in the latest version of the PCI DSS.

How will PCI 3.1 affect SecurityMetrics customers?

SecurityMetrics has been scanning for SSL vulnerabilities for over a decade. Specifically, we have been scanning for SSL version 3 vulnerabilities, such as the POODLE vulnerability, since October 2014.
    PCI 3.1 SSL TLS
  • SecurityMetrics vulnerability scans do not currently fail merchants using SSL or TLS 1.0 as long as they have provided documentation showing they have a TLS Mitigation and Migration plan.
  • This exception will expire when the June 30, 2018 deadline hits. Customers that have not disabled SSL and Early TLS and rescanned by that date may be knocked out of compliance due to a failing scan contact SecurityMetrics Support if you have questions. 
Follow for more data security articles like this

What about HTTPS and ecommerce?

Because virtually all ecommerce websites have SSL/TLS enabled for their cryptography, they are at the highest risk from SSL/TLS vulnerabilities. New e-commerce websites must not use or support SSL/early TLS.

The PCI Council also stated that web browsers will begin prohibiting SSL connections in the near future, preventing users from accessing web servers that haven’t migrated to a more modern protocol.


What about my POS/POI terminal?

The PCI Council decided that Point of Sale (POS) or Point of Interaction (POI) devices that aren’t susceptible to all known exploits of SSL and early TLS may continue to be used, even after the deadline.

Merchants who continue using old POS or POI devices should understand that because SSL is outdated technology, it may be subject to future security vulnerabilities. The PCI Council recommends that POI environments update to TLS v1.1 or later if possible.

How do I know if I’m using SSL/early TLS?

SSL and TLS are widely used, so I recommend contacting your terminal providers, gateways, service providers, vendors, and acquiring bank to determine if the applications and devices you use have this encryption protocol. If you’re writing your own software, please check with your development department.

Examples of applications that likely use SSL/early TLS
  • Virtual payment terminals
  • Back-office servers
  • Web/application servers

What if I’m using SSL/early TLS?

The PCI Council has released guidance on migrating from SSL and TLS, as well as examples and recommendations on how to deal with this requirement in their Migrating from SSL and Early TLS information supplement.

If you use SSL/early TLS, but don’t need to:

If you have existing implementations of SSL and early TLS that you don’t need for regular business operations, immediately remove or discontinue all instances of SSL/TLS. Do not use any new technologies that use SSL/TLS.

If you use SSL/early TLS, and need to continue using:

First, remember not to implement any new technologies that use SSL/TLS. But, if you need to continue using SSL/early TLS to continue regular business operations, here are some examples of what you can do:
  • Upgrade to a current, secure version of TLS configured to not accept fallback to SSL or early TLS.
  • Encrypt data with strong cryptography before sending over SSL/early TLS (for example, use field-level or application-level encryption to encrypt the data prior to transmission)
  • Set up a strongly-encrypted session first (e.g. IPsec tunnel), then send data over SSL within the secure tunnel
  • Check firewall configurations to see if SSL can be blocked
  • Check all application and system patches are up to date
  • Check and monitor systems to ID suspicious activity that may indicate a security issue
Please note that organizations with existing implementations of SSL and early TLS must have a Risk Mitigation and Migration Plan in place. According to the PCI Council, this document will “detail [your] plans for migrating to a secure protocol, and also describes controls [you have] in place to reduce the risk associated with SSL/early TLS until the migration is complete.”

You will need to provide your Risk Mitigation and Migration Plan to your PCI assessor as part of the PCI DSS assessment process.

Learn more about the Risk Mitigation and Migration Plan in the PCI Council’s migrating from SSL and Early TLS information supplement.

Need help discontinuing the use of SSL/TLS? Contact our PCI support team.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Senior Vice President of Security Assessments at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.


Lessons from Data Breaches in 2017 and What to Expect in 2018


Which data breach predictions came true in 2017 and what to expect for 2018.

David Ellis
SVP, Investigations
GCIH, QSA, PFI, CISSP
This blog is based on Dave Ellis’s Webinar, “Lessons Learned from 2017 Forensic Investigations." You can download and watch the webinar here.

SecurityMetrics' Forensic Investigations Team has been helping business recover from data breaches and theft for over eighteen years. We analyze the data from those investigations and use it to inform our customers, predict breach trends, and better protect merchants.

How did our predictions for 2017 play out?

  • Insecure remote access will continue to plague organizations

    • Yes; continues to be the most common problem we see.

  • Large-scale POS breaches will decrease, but employees will remain high-risk

    • This certainly happened. We’ve seen the large-scale breaches decline, and employees were the most common weak point (e.g., opening phishing emails).

  • Overall number of breaches will temporarily decrease

    • This is proven true according to our investigations. POS breaches have declined with the advent of EMV. 

  • Ecommerce breaches will increase

    • In 2017, 56% of the payment card investigations we performed were in ecommerce, up from 38% in 2016. 

  • Increased attacks against healthcare targets

    • Yes; we saw near-two-fold increase in healthcare breaches last year.

  • A resurgence of ransomware

    • According to Malware Bytes, ransomware was the most prolific gainer of 2017. Ransomware rates tripled in number from 2016; 60% of malware payloads installed on commercial systems were ransomware. 

INFOGRAPHIC: 2017 PCI Data Breach Trends 

Many of our readers want to know: what does a cyberattack typically look like? How does an attacker gain access to a system in the first place? How do they steal the information, and what do they do with it?

It pays to understand the steps and patterns of a hacker—plus, it brings to light how important it is to comply with security standards regarding password complexity and secure remote access.

An attacker’s activities will typically include:

  1. Scan internet for open remote access ports. The majority of attacks are not specifically targeted. More commonly, an attacker will start by launching a port scan over a large range of IP addresses looking for open ports that correspond to remote access applications. If they see the company is running remote access software, they will likely attempt to breach through that software. 

  2. They will enter ‘administrator’ or ‘admin’ for the username, and now they just need to “bruteforce” a password using an online password list. 

  3. Test remote access credentials.

  4. If successful, they gain system access and ascertain where they are (e.g., whether they have gained access to a healthcare organization, retail business, or home network).

  5. At this point, an attacker might monitor your activity by installing a keylogger.

  6. Download malware onto the system or encrypt critical files. 

  7. Attacker will capture confidential information or contact the owner of the system and levy ransom demands. 

How does stolen data turn into money for hackers?


Attackers might personally use the credit card numbers online or to buy gift cards or prepaid cash cards.

Or—they could be a part of a large organization made up of talented individuals. Organized hacking is like the “new mafia.” These operations are highly systemized, and their employees are probably more motivated than you or I at our jobs. Widespread across the globe, hacking organizations post their offerings on the dark web, and aim to sell the credit card information per number or in bulk.

Most common security failures in 2017:


  • Firewalls: About 52% of the cases we investigated had inadequate firewall configurations. In some cases, there were no firewalls at all, but most often they weren’t properly configured.
  • Passwords: Similar to when firewalls are left on default configurations, passwords can be left on default settings as well. Or the password might be too simple, like “password” or “12345.” A few years ago, there was a large breach where more than one billion passwords were “lost.” They weren’t actually lost because the hacker that stole them had cleverly inserted them into a brute-force hacking tool (which he made available for sale to others) that can fly through a system and quickly attempt different passwords. To mitigate these attacks, we recommend that your system lock down after three failed password attempts. 
  • Antivirus: In many of the data breaches we investigated, there was no antivirus installed, or it was expired on some or all of the key systems. And in cases where it was installed, inconsistency was often a problem. The antivirus software wasn’t always installed on all endpoints. We found that 72% of breached companies had adequate antivirus running. But antivirus still makes the list because in the close to 30% of the other cases that inadequacy was a direct contributor to the data breach. 
  • Secure access: Determines who is and is not allowed to access information on your system. Secure access could be compromised with a weak authentication password but is usually due to a lack of multi-factor authentication. There should not be any areas with sensitive or protected information to which someone could log in without multi-factor authentication. Multi-factor authentication will prove to be a crucial security principle as time goes on. 

Other security issues:

  1. More than one primary function per server. If you have a device that’s used to take patient info or process credit card info, the more you can segment and separate that device from devices that are used to conduct more routine day-to-day activities, the easier it will be for you to provide high-level security for just a few key devices in your critical data environments, rather than across your entire network.

  2. Application security updates. Ignoring patches continues to be a problem. For example, when payment applications discover security flaws, they will issue security patches. But we see many investigations where organizations failed to update with current patches, even though they had been supplied months (and in some cases, years) before.


SEE ALSO: 5 Steps to Manage a Data Breach

How did healthcare do with security in 2017?


The FBI reports(link) increased attacks against healthcare organizations in 2017: 88% of ransomware attacks last year targeted healthcare organizations. The other 12% were targeting individuals or non-healthcare businesses. Hackers recognize that if they can hold hostage patient information or doctors’ notes, the healthcare industry has to act immediately and is more likely to pay a ransom.

89% of studied healthcare organizations reported a breach involving the loss of patient data in the past two years. In our investigations, we found that 78% were compliant with the HIPAA requirement to encrypt patient data, 55% complied with reviewing firewall rules at least yearly, and only 26% complied with using multi-factor authentication for remote access.

Top organizational vulnerabilities

In our opinion, the top vulnerabilities organizations should focus on are:
  • Insecure remote access

    • Tip: Insist on multi-factor authentication with strong passwords and tokens for all environments containing high value data. 

  • Employees 

  • BYOD procedures 

    • Tip: Bring Your Own Device (BYOD) can be a problem. For example, an employee that uses their work computer on a home network inadvertently downloads a virus. The employee then introduces the virus into the work environment when they log back into the work network. Your work environment should scan devices for viruses when it detects a new login. 

  • 3rd Parties
    • Tip: Know where your data flows and is stored. Conduct risk assessments that include 3rd-party service providers. Do your due diligence with service providers, making sure you have policies, procedures, and agreements on file regarding their security. 


Top 10 Tips to avoid data breaches

  1. Educate staff employees: Hold regular trainings with special focus on phishing/spoof emails. 10% of phishing email links are clicked on. Also train your staff to recognize and guard against social engineering. Teach them to question what seem like unusual requests for information (like W2s or personal data).

  2. Install updates and patches: Consistently monitor application updates and watch for flaws and subsequent patches. 

  3. Develop secure code, then test: Enforce a secure software development lifecycle. For example, follow NIST 800-115 or the OWASP Testing Guide. 

  4. Vulnerability Scans and Penetration Tests: Schedule scans often and regularly (e.g., quarterly) and after any significant network changes. Conduct penetration tests on critical systems at least yearly and after any significant network changes. Be sure to include social engineering tests. 

  5. Configure and review logs: The best way to find out about a breach is from your own internal review. Someone in your organization needs to have eyes on security logs daily. Create and implement a process to respond to intrusion detection system (IDS) and file integrity monitoring (FIM) alerts in real time. 

  6. Risk assessments: Hold a risk assessment at least annually and after any significant network changes. 

  7. Control admin access:  Update default usernames like “admin.” Implement multi-factor authentication and restrict access to sensitive data. 

  8. Segment your network: (link) Implement network segmentation by isolating less-secure networks from high-security networks. Ensure that a breach of the less-secure network cannot affect the high-security network. 

  9. Hide sensitive data: (link) Chances are you need to store some sensitive data at your business, so at a minimum, sensitive data should be encrypted and properly secured. Be certain to test your backups to ensure that you will be able to restore from them after a data breach. (This will be your greatest defense against a successful ransomware attack.)

  10. Develop and test an incident response plan: (link on how to do one) Creating a thorough incident response plan (IRP) (and testing it annually) will help coordinate your response during and after a security incident, minimize an incident’s impact, and restore your operations as quickly as possible. 

2018 Forensic Predictions 

  1. Ecommerce breaches will continue to increase, as will attacks against healthcare. Ecommerce increased last year, and it will continue to do so. We will probably settle in at a rate of about 80% of investigated breaches that occur in ecommerce environments. 

  2. Smaller merchant breaches will come under greater scrutiny. It used to be that virtually all merchant breaches were investigated. But about five years ago, the card brands softened their mandates to reduce the financial burden for smaller merchants. While a breach of a single small merchant doesn’t typically expose a large number of credit card accounts, the collective total of several small merchant data breaches does. As the number of point-of-sale (POS) card-present breaches decreases, you will start to see increased pressure for small merchants to take more definitive actions when they’re under the suspicion of a data compromise. 

  3. Coordinated attacks that start with your cell phone. We had an attack last year that started with a breached cell phone, which led to the personal computer in the home, then on to the owner’s business (which was n the healthcare industry), then the breach spread to all of the devices in that environment. You may also see more attacks aimed at individuals—and those may be likely to start with a cell phone. 

  4. Passwords may not be the security you’re looking for. We will start to see next year—and more so in the coming years—that passwords will no longer be considered an element of security. There is present technology that can search and break password hashes at the rate of 600 billion attempts per second. This means that attackers could span every possible combination of keys possible, in most languages, in just a few days. As developers put more steam behind this tool, the time and resources needed to break passwords will greatly reduce, regardless of password complexity level. 

  5. Artificial intelligence (AI): on your side and against you. We will likely start to see security tools with artificial intelligence that can detect and adapt to data breaches. But we will also likely see AI on the attackers’ side—with malware that can self-move, self-manipulate, and self-hide in response to what it sees a user do. AI will start to show up with increasing frequency, and it’s going to make the future of data security very interesting. 

Learn more about our Incident Response Services or inquire about a PCI or HIPAA Audit

David Ellis (GCIH, QSA, PFI, CISSP) is Director of Forensic Investigations at SecurityMetrics with over 25 years of law enforcement and investigative experience. Check out his other blog posts.

PCI Council Releases PCI DSS 3.2.1: What You Need to Know

Learn what’s changed in the latest version of the PCI DSS.

PCI DSS version 3.2.1

The Payment Card Industry Security Standards Council (PCI SSC) recently announced the release of the PCI Data Security Standard version 3.2.1.

The Council previously released version 3.2 in April of 2016 to replace version 3.1, which brought with it some big changes, among which were new requirements for service providers and additional guidance about multi-factor authentication.

So what has changed between versions 3.2 and 3.2.1?

Changes to standard characterized as "clarifications" 

All of the changes in this latest version 3.2.1 are characterized by the PCI Council as clarification—as
opposed to additional guidance or actual changes in requirements. The intent of clarification from the PCI Council is to ensure that “concise wording in the standard portrays the desired intent of requirements.”

Many of the changes involve simply removing requirements’ effective dates which have passed or correcting minor punctuation and format issues. However, there are a few items of clarification regarding SSL/early TLS and multi-factor authentication that are worth noting:

  • “Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS” has been renamed “Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS for Card-Present POS POI terminal connections.” 

  • In Appendix A2, requirements A2.1 – A2.3 were updated to focus only on the allowance for POS POIs that are not susceptible to known exploits and their service provider termination points to continue using SSL/early TLS.

  • In “Appendix B: Compensating Controls,” Multi-factor authentication was removed from the compensating control example, as MFA is now required for all non-console administrative access. The use of one-time passwords (tokens) as an alternative potential control for this scenario was added.


Stay updated to maintain compliance 

While these changes are not likely to affect your day-to-day data security routines or require much extra time or money, it’s important to use the latest version of the PCI DSS to avoid misunderstandings and potential gaps in security.

You can read a full and detailed summary of changes between PCI DSS version 3.2 and 3.2.1 here.

If you need help with PCI compliance or would like to know more about PCI audits, contact us here.


How Much Does HIPAA Compliance Cost?

Realistic HIPAA security budgets vs. wishful thinking.

Jen Stone
MCSIS, CISSP, QSA
HIPAA compliance is rarely allocated the resources it requires. And this trend extends beyond just small organizations with limited security budgets. Lack of budget is a plague that affects risk and compliance officers at health organizations of all sizes. 



This post will give you the information you need to more accurately plan your HIPAA budget.

SEE ALSO: Five Things to Consider When Making a HIPAA Security Budget

What does the HHS think HIPAA compliance costs?

The HHS gave an interesting estimation (see Table 1) of how much HIPAA compliance might cost, shortly after they released the HIPAA Final Rule in 2013.

Per organization, they estimated:
  • $80 for an updated Notice of Privacy Practices
  • $763 for breach notification requirement updates
  • $84 for business associate agreement updates
  • $113 for security rule compliance
Grand total per organization: $1,040

This estimate is likely inaccurate, especially when considering the complexities of the Security Rule. When the Security Rule was added back in 2003, it included 75 new requirements and 254 points for organizations to validate to, most of which are quite technical.

The following is an example of a "validation point:"

164.308 – Acquire IT Systems and Services (1 requirement)
Based on the OCR audit protocol, here are the validation points:
  • Interview management to verify that Policy and Procedures exist (P&P)
  • Determine if the P&P are approved and updated on a periodic basis
  • Obtain and review the documented policy (what is required) and procedure (how we are supposed to accomplish the task)
    • Where are P&P stored? 
How is it disseminated to staff?
    • How do we document staff have read, understand and agree to abide by the policy?
  • Determine if the P&P are approved and updated on a periodic basis
In this one example you can see that this single requirement (1 of 75) has three core validation points (3 of 254) with several more minor validation points.

Looking at the math, and the HHS’ estimated $113 allotted to the security rule, that means only $4 is allowed per requirement. It would be a stretch for healthcare entities to accurately validate each new security point for only $4 worth of labor, technology, and implementation. That’s not even taking into account that you will likely need to add (or, at the very least, upgrade) hardware and applications.

Variables that affect HIPAA compliance cost

The cost of HIPAA compliance depends on your organization. Here are a few variables that will factor into the cost of your overall compliance.

  • Your organization type: Are you a hospital, business associate, HIE, healthcare clearinghouse, or another type of healthcare provider? Each will have varying amounts of protected health information (PHI) and risk levels.
  • Your organization size: Typically, the larger the organization, the more vulnerabilities it has. More workforce members, more programs, more processes, more computers, more PHI, and more departments add up to more HIPAA cost.
  • Your organization’s culture: If data security is one of upper management’s top priorities, you have probably already invested in a cybersecurity program. If management has been hesitant to dedicate budget to security, compliance with HIPAA will cost more because you will have more distance to make up.
  • Your organization’s environment: The type of medical devices, the brand of computers, the kind of firewalls, the model of backend servers, etc. can all affect HIPAA compliance cost. If cybersecurity was considered when purchasing, implementing and maintaining these devices, the costs to comply with HIPAA at this point will be lower. If security was not considered, costs to get in line with HIPAA will be greater.
  • Your organization’s dedicated HIPAA workforce: Without a dedicated HIPAA team, you might not know how far you are from closing the HIPAA gap. Even with a dedicated HIPAA team, organizations usually require outside assistance or consulting to help them meet HIPAA requirements.

The cost of a data breach

Costs related to a HIPAA program can seem daunting, but they are small in comparison with not protecting PHI. Here are a few data breach costs, fines, and penalties you may not have considered. 
  • HHS fines: up to $1.5 million/violation/year
  • FTC fines: $16,000/violation
  • Class action lawsuits: $1,000/record
  • State attorneys general: $150,000 – $6.8 million
  • Patient loss: 40%
  • Free credit monitoring for affected individuals: $10-$30/record
  • ID theft monitoring: $10-$30/record
  • Lawyer fees: $2,000+
  • Breach notification costs: $1,000+
  • Business associate changes: $5,000+
  • Technology repairs: $2,000+
SEE ALSO: How Much Does a Data Breach Cost Your Organization?

When you look at the high costs paid by organizations found in violation of HIPAA, it’s obvious the consequences are meant to penalize those who don’t adequately protect patient information.

So, how much does HIPAA compliance cost?
If you are a large provider, you’ll probably benefit most from an onsite HIPAA compliance audit. Security experts examine your organization for security risks, provide guidance as you remediate any problems, and consult on the implementation of any outstanding HIPAA requirements.

Your onsite auditor should work with you to complete both your HIPAA risk analysis and risk management plan. Learn the pros and cons of a HIPAA audit here.

If you don’t have the budget for an onsite audit, you’ll need to find a HIPAA expert to help you get through the risk analysis and risk management plan process. Look for an expert who offers technical support when you have questions. Experts will likely recommend you receive external vulnerability scans to find weaknesses in your systems, and hire penetration testers (ethical hackers) to test your system. If you haven’t already, you’ll likely need to purchase HIPAA policy templates and start your employee training.

Taking all the above into consideration, and remembering that this estimate depends on various factors at your organization, here’s how much HIPAA compliance might cost you:

If you are a small covered entity, HIPAA should cost:

  • Risk Analysis and Management Plan ~$2,000
  • Remediation ~ $1,000 - $8,000
  • Training and policy development ~ $1,000-2,000
Total: $4,000 - $12,000


If you are a medium/large covered entity, HIPAA should cost:

  • Onsite audit ~ $40,000+
  • Risk Analysis and Management Plan ~ $20,000+
  • Vulnerability scans ~ $800
  • Penetration testing ~ $5,000+
  • Remediation ~ Varies based on where entity stands in compliance and security
  • Training and policy development ~ $5,000+
Total: $50,000+, depending on the entity’s current environment

Jen Stone (MSCIS, CISSP, QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.