PCI

What is HITrust Pay?

ZenGRC Team · February 21, 2019 ·

Compliance with the Health Insurance and Portability Act (HIPAA) initially appears to apply only to the healthcare industry. However, HIPAA also requires healthcare provider business associates to maintain security and privacy controls over protected health information (PHI) and electronic PHI (ePHI). For payer organizations, this requirement means aligning data security protections to HIPAA.

HiTrust Pay

What is a “Business Associate”?

Under HIPAA, a business associate is any individual or entity who provides services to a covered entity. This definition includes explicitly billing and repricing. If you’re working with a covered entity and offering payment processing, then you also need to be HIPAA compliant.

What are the PCI DSS requirements?

Payment processors already understand stringent and prescriptive security and data regulations. The Payment Card Industry Data Security Standard (PCI DSS) prescribes twelve different requirements for securing data. PCI DSS focuses on protecting payment card information such as account number in conjunction with either cardholder name, the card’s expiration date, or its service code. At its core, PCI intends to protect cardholder data (CD) so that no one can steal it and spend the payee’s money.

What are the HIPAA requirements?

HIPAA requires business associates to maintain control over information including but not limited to demographic information, medical history, test and lab results, mental health conditions, and insurance information. At its core, HIPAA intends to protect people’s private health information which often includes more data points. Those additional pieces of information can enable a malicious actor to create a false identity.

Why PHI is more valuable than CD

Health information records contain more data points than cardholder data. Although a credit card or personal account can lead to unauthorized charges, health records incorporate date of birth, social security number, and additional identifiers that can allow malicious actors to create false tax return filings or create new bank accounts. Ultimately, unauthorized access to CD leaves a person’s financial identity at risk while unauthorized access to PHI or ePHI places the individual’s historical identity at risk.

Where PCI lacks HIPAA protection

The HIPAA Security Rule focused on ePHI and created three primary safeguards: technical, administrative, and physical. Additionally, HIPAA incorporates a Breach Notification Rule and Privacy Rule. Although PCI compliance aligns to some of the Security Rule requirements, it does not meet the Breach Notification and Privacy requirements.

Thus, payment processors seeking to work with HIPAA covered entities must incorporate additional controls and processes.

How HiTRUST enables payer security

HIPAA compliance for business associates rapidly becomes overwhelming.
The Health Information Trust Alliance (HiTRUST) brought together all the relevant standards that enable HIPAA compliance into a single common security framework (CSF). The HiTRUST CSF enables covered entities and business associates to work within a single program that creates a certification process for both groups. As such, the certification allows a business associate, such as payment processor, to “assess once, report many.”

This process provides continual assurance that, as a vendor, the payer security processes maintain the integrity and confidentiality required for HIPAA compliance.

What are the types of HiTRUST CSF assessments?

A business associate can choose to engage in either the self-assessment process or the validated assessment process.

The CSF self-assessment uses the methodology, requirements, and tools contained within the CSF Assurance program. After an organization submits a self-assessment, HiTRUST engages in limited validation.

The validated assessment begins with a self-assessment but then requires a certified CSF assessor to conduct and score the assessment. Once validated by the CSF assessor, the organization’s controls can be deemed CSF certified.

Why obtain HiTRUST Certification?

The HiTRUST Third Party Assurance Program allows organizations to create a streamlined reporting and validating process that eases HIPAA compliance across the supply stream.

Engaging in the CSF self-assessment offers insight into control management. However, since it does not incorporate the same level of external assurance over program effectiveness, it lacks the weight of certification.

HiTRUST CSF certification incorporates both the HIPAA risk assessment process as well as the NIST Cybersecurity Framework control effectiveness review. By bringing these two together under a single compliance umbrella, as well as incorporating other standards that apply to HIPAA, the HiTRUST certification enables third parties to assure their customers that they engage in the due diligence necessary for maintaining ePHI securely.

Because certification requires additional levels of review and more detailed reporting, most covered entities and business associates rely on certification when compared to self-assessment. Many healthcare organizations establishing business partnerships require their third-parties to obtain and maintain HiTRUST certification. Thus, many payer organizations are aligning their compliance to the CSF.

Is HiTRUST certification the same as HIPAA compliance?

The two are similar yet distinct. HiTRUST certification acts as a means of HIPAA compliance. Since HiTRUST focuses on risk mitigation, organizations can choose recommended controls based on their use cases. Each self-assessment and CSF assessment starts with the organization’s organizational, regulatory, and system risks then aligns those to the necessary security controls.

However, while this enables compliance with the Security Rule, business associates need to ensure that they also maintain compliance with the Breach Notification and Privacy Rules.

eBook: PCI DSS Guide to Scoping

ZenGRC Team · January 4, 2019 ·

For merchants who process payment cards, compliance with the Payment Card Industry Data Security Standard (PCI DSS) is mandatory for doing business. While PCI DSS establishes prescriptive requirements for protecting data, many companies struggle with understanding how to determine what networks and systems fall within the PCI DSS scope. For many merchants, the most frustrating and confusing part of maintaining compliance with the PCI Security Standards is determining what networks and system components need to be protected under the rigorous standard.

Understanding PCI DSS

What is the Payment Card Industry Data Security Standard?

The five major payment card companies, American Express, Discover Financial Services, JCB International, MasterCard, and Visa, Inc. banded together to create the Payment Card Industry Security Standards Council (PCI SSC) to establish best practices for protecting cardholder data. The organization wanted to create a series of standards for how to process payments – to protect their customers as well as themselves. These became the Payment Card Data Security Standard.

What is cardholder data (CHD)?

The standard defines CHD as any personally identifiable information (PII) that can link an individual to their a credit or debit card. This card data includes the primary account number (PAN) in combination with either the cardholder name, expiration date, or service code.

What is the cardholder data environment (CDE)?

Under the standard, any computer or networked system that processes, stores, or transmits this CHD needs to be protected using the specified controls listed in the PCI DSS requirements. The CDH includes system components such as network devices, servers, computing devices, and applications. These can be security services, virtual components, network components, server types, applications, or anything connected to CDE.

The standard defines “system components” as network devices, servers, computing devices, and all applications, providing six specific examples:

Security services, segmentation services, or services impacting security
Virtual components including machines, switches/routers/appliances, applications/desktops, and hypervisors
Network components
Server types
Internal and external applications
Anything connected to CDE

What is network segmentation?

Under the PCI standard, your CDE needs to be separated from any other systems, software, and networks used within your enterprise. Any unprotected connection to the CDE, internal or external, places your organization at risk for fines.

What is PCI DSS scope?

PCI compliance starts with determining your CDE. Determine what systems, networks, devices, and applications store CHD, and therefore are part of your CDE, is the process of deciding your PCI scope. All these systems, devices, networks, and applications that need to be separated from the rest of your IT infrastructure and protected by the prescriptive requirements.

Why do I need to create a data flow?

Understanding your IT infrastructure not only requires you to focus on the individual system components that store, process, and transmit data, but also the way the data moves between them. For example, if CHD travels across a network and that network also transmits data for an application that does not impact CHD, the app is also connected to your CDE.

Therefore, you need to apply the PCI controls to that application as well to ensure the security of the CDE. If you don’t protect that application, a malicious actor can use it to obtain unauthorized access to your network which ultimately puts cardholder data at risk. Understanding the way data flows not only within your CDE but across your entire infrastructure allows you to ensure stronger threat mitigation.

What is an SAQ?

To ease the burden on merchants using vendors to enable PCI compliance, the PCI Security Standards Council created a Self-Assessment Questionnaire that allows you to review your technologies to see if they meet the data security requirements. For businesses that use PCI SSC approved point-to-point encryption (P2PE) hardware, this streamlines the requirements by more clearly defining, and limiting, the CDE.
A P2PE is a device used in brick-and-mortar (card present) and mail/telephone order merchants. To qualify for this lower standard, the merchant must attest that they

only process payments using a P2PE device approved by the PCI SSC
the only devices that interact with P2PE device are supported Point of Interaction (POI) devices approved for use with it
have no other electronic storage, transmission, or collection locations for cardholder data
do not store legacy information electronically
have implemented all the controls required by the P2PE solution.

In this case, the merchants limit their PCI scope to just these devices and their technologies.

What is a Qualified Security Assessor (QSA)?

Your QSA is the external party certified by PCI SSC who oversees your PCI compliance. In short, they act as external auditors who go through PCI specific training.

As such, the first thing they will look at when they review your PCI compliance is whether you have appropriately scoped your CDE. If you haven’t correctly defined your compliance scope, then you won’t be able to set related controls in compliance with the requirements. Thus, before they review any other controls, they will determine whether you’ve located all the right system components.

What about service providers?

As merchants increasingly use Software-as-a-Service (SaaS) platforms to make payment processing easier, those suppliers are also in-scope systems for PCI compliance if they transmit, store, or process CHD.

Your service level agreement (SLA) should clearly outline the PCI-DSS requirements covered by you and the services provider.

To prove its compliance, your vendor needs to provide documentation assuring:

Annual assessment done independently and provided to their users.
Multiple on-demand assessments at the request of each client.

If the service provider chooses to do its own annual assessment, the customers need to make sure that it covers their compliance needs and is part of the contract.

How to Use ZenGRC for PCI Compliance

ZenGRC acts as a single source of information for PCI compliance. With ZenGRC’s built in PCI mapping capabilities, you can easily align your current controls to the standard’s requirements.

Moreover, ZenGRC’s dashboard provides real-time insights into your organization’s control effectiveness providing you with continuous monitoring capabilities as required by PCI.

The workflow management and risk management capabilities within the ZenGRC platform offer merchants a way to communicate with internal stakeholders to ensure that you manage high priority risks first.

For more information about how to determine your PCI scope and protect your CDE, download our ebook “PCI DSS: Steps to Successful Scoping.”

PCI Log Management Requirements For CISO’s

ZenGRC Team · September 4, 2018 ·

Whether you’re in the healthcare, retail, or hospitality industry, you’re going to need to protect your customer information if you collect payments. The Payment Card Industry Data Security Standard (PCI DSS) not only sets the standard for cardholder data (CD), but it also enforces the standard with penalties.

PCI DSS Logging and Log Monitoring Requirements

What is the Payment Card Industry Data Security Standard (PCI DSS)?

In the early 2000’s, the five major payment card companies, American Express, Discover Financial Services, JCB International, MasterCard, and Visa, Inc. banded together to create the Payment Card Industry Security Standards Council (PCI SSC). The organization wanted to create a series of information security standards processing payments that protected customers from identity theft and the card industry from paying for data breaches.

PCI SSC worked together to establish “best practices” for protecting information which became standardized as PCI DSS.

What Are The Penalties for Noncompliance?

While PCI DSS is considered a “standard” and not a regulation, many merchants incorrectly assume compliance is optional. Noncompliance leads to consequences that can cause business failure.

Card brands and acquiring banks can, at their discretion, fine noncompliant merchants anywhere from $5,000 to $100,000 per month for a violation. Depending on an organization’s size, these fines can be either crippling or devastating.

Who Needs to Be PCI DSS Compliant?

Regardless of your size or industry, any company accepting, transmitting, or storing cardholder data must maintain PCI DSS compliance.

What is PCI DSS Requirement 10?

PCI DSS Requirement 10 focuses on monitoring access to networks and data. In its most broad definition, Requirement 10 states:

Requirement 10: Track and monitor all access to network resources and cardholder data

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

Essentially, Requirement 10 requires you to continuously monitor the user access to your environment. Setting up user access controls is the first step to maintaining a secure cardholder data environment (CDE), but you also need to ensure that those controls work.

Embedded within Requirement 10, however, are 39 subparts. Since PCI DSS is a highly prescriptive standard, it sets out a clear list of the steps and documents needed to meet its requirements.

What records are necessary for Requirement 10 Compliance?

If you’re looking to be PCI DSS compliant, the standard not only lists the sections and subsections and parts of subsections, but it also incorporates Guidance to help understand effective control review. As such, the following steps can help you log data necessary to prove your compliance:

Create a system or process linking user access to the system components accessed and make sure you can trace suspicious user activity to a specific user.
Generate audit trails that prove the system administrator receives suspicious activity alerts and follows up on them.
Record all individual accesses to the CDE to show that new or unauthorized user accounts have not accessed the systems and networks.
Ensure you collect records of activities performed by “administrator” or “root” accounts that show potential misuse of these accounts and can trace the issue to a specific action and individual
Maintain file integrity of audit logs by having a way to identify changes, additions, and deletions to them.
Record invalid login attempts to trace “brute force” attacks or password guesses.
Maintain records that allow you to trace activities indicating manipulation of authentication controls by attempting to bypass them or impersonating a valid account, including but not limited to records that verify mechanisms, elevation of privileges, and any changes/additions/deletions to root or administrative accounts.
Document any pauses or restarts to your audit logging processes.
Maintain records to show that system-level object, such as databases or stored procedures, have not been created or deleted by unauthorized accounts.
For all system components, maintain an event log that records user identification, event type, date/time stamp, success/failure indication, event origination, and affected data, system component or resource identity/name.
Synchronize clocks across systems to maintain exact sequences of events for forensics teams.
Use “principle of least privilege” for audit log access to maintain security and integrity of the information.
Backup logs to a centralized server or media that maintains data integrity.
Write logs directly, or offload or copy from external systems to a secure internal system or media.
Use file-integrity monitoring or change-detection systems to ensure notification of audit log changes that may indicate a compromise.
Engage in regular log reviews either manually or by using a log harvesting, parsing, and alerting tool.
Engage in daily review of security daily for notifications or alerts indicating suspicious activity and critical system component logs.
Schedule periodic reviews for all system components that indicate potential issues or attempt to gain access to sensitive systems by using less sensitive systems.
Document investigations of exceptions and anomalies.
Retain all records for at least a year.
Ensure employees are trained and aware of security policies and monitoring.

Service providers are subject to the following additional requirements:

Establish formal procedures to detect and alert critical security control failures, such as a firewall erasing rules or going offline.
Document evidence supporting the response to a security failure, including the processes and procedures as well as the actions and responses.

How ZenGRC Eases Best Practices For PCI DSS Audit Log Management

ZenGRC’s system-of-record enables organizations to store all their information in a single location. Collecting all your audit log information in a single place allows you to manage audit information and document your compliance activities.

With a single source of information, your audit logging staff can communicate efficiently with one another. Our role-based authentications enable audit log security and integrity since only the people who need access can interact with the information.

Finally, our system-of-record enables your audit log review staff to trace outstanding tasks without emails. This capability not only makes communication easier but protects the data by keeping it within our protected platform rather than insecure emails.

Managing audit information in a single location helps you detect real-time risks and prove continuous monitoring by documenting all your ongoing compliance activities.
For more information about how ZenGRC eases the burden of audit log management and analysis, contact ZenGRC to schedule a demo.

PCI Compliance & Network Segmentation

ZenGRC Team · June 19, 2018 ·

Network segmentation acts as the starting point for determining the scope of your Payment Card Industry Data Security Standard (PCI DSS) compliance journey. Segmentation means creating controls focused on the data’s security needs. To appropriately meet the PCI network segmentation requirements, you need to understand the standard’s purpose and objectives.

PCI DSS Network Segmentation

What is the cardholder data environment (CDE)?

PCI DSS defines cardholder data (CHD) as personally identifiable data associated with someone’s credit or debit card. This definition includes the primary account number (PAN) in conjunction with either cardholder name, expiration date, service code, or sensitive authentication card data.

In short, CDH constitutes any information that could be used to steal an identity or make fraudulent charges to someone’s card.

The cardholder data environment constitutes any computer or networked system that processes, stores, or transmits this information. The CDH includes system components such as network devices, servers, computing devices, and applications. These can be security services, virtual components, network components, server types, applications, or anything connected to CDE.

If employees or systems can access CHD on something, then that needs to be set off separately from all other areas of your company.

What does PCI DSS mean by network segmentation?

Network segmentation requires looking at the way information travels on your systems. Think of your CDE as a river and the CHD as a kayak navigating the rapids. Just like rivers have multiple access points for boats, networks have various data access points. Networks act like rivers with tributaries that are connected to them. If your CHD can float down a path on your network, you need to either protect that tributary or build a dam.

For example, PCI DSS defines connectivity as physical, wireless, and virtualized. At any point on that river, CHD can enter. Physical connectivity may be a USB drive. Wireless connectivity includes Wireless LANs and Bluetooth connections. Virtualized connectivity incorporates shred resources such as virtual firewalls or virtual machines. Each of these data access points needs to be secured.

How do companies scope systems?

PCI DSS scoping requires critically evaluating all the different data access points and tributaries on your CDE river.

A PCI DSS assessment starts with cataloging how and where you receive CHD. Walking up and down the banks of your CDE, you need to find all payment channels and methods for accepting CHD and then follow the information’s journey from collected through destruction, disposal, or transfer.

Next, locate and document the places throughout your CDE where you store, process, or transmit data. This identification means understanding how not only who handles data, the processes and technologies that touch the data as it flows through your networks.

After you’ve tracked the information’s flow through your organization’s networks, you want to make sure that you’ve incorporated all processes, system components, and people who influence the CDE. This step differs from the last because it requires you to look outside of those that interact with the information and focus on those who drive the environment.

Once you’ve reviewed your data river, you need to create controls to protect the information. In the same way that some rivers have landings to help protect boaters accessing certain points, you need to have controls. You also need to determine how to limit where the information can go and who can access it. To do this, you want to put up the data security version of dams, including firewalls and encryption methods.

After you’ve established control, you need to make sure that you apply them to all in-scope system components, processes, and personnel.
Finally, and most importantly, you need to monitor controls and make sure to make changes as your CDE evolves.

Are there any out-of-scope systems?

The Payment Card Industry Security Standard Council (PCI SSC) defines out of scope systems as those with no access to any CDE system. Increasingly, finding out-of-scope systems is difficult.

The PCI SSC requires that the system component must not store, process, or transmit CHD AND must not be connected to any network segment that touches CHD AND must not connect to any system in the CDE AND cannot gain access to or impact a security control of the CDE AND doesn’t meet any previously discussed criteria.

Going back to the river analogy, even the trees in the neighboring forest might be in scope if they can access the same water table as your river. Therefore, before declaring a system out-of-scope, you need to think very carefully about it.

Can organizations transfer their risk using third party service providers?

Third parties and service providers also fall within the scope of your PCI security standards compliance.

Third parties and service providers are the forest rangers for your river. These business partners, entities providing remote support services, or other service providers may engage with your environment and therefore can place it at risk. Just as a forest ranger may move a branch that topples a kayak, so your third parties can impact your PCI DSS compliance. Therefore, you need to engage in third-party monitoring and manage your vendor ecosystem.

If you use a third-party service provider, you need to assess their services carefully. The contract should delineate the parts of the PCI-DSS requirements covered by you and the services provider.

The service provider needs to prove its compliance.

Vendors can either provide an annual assessment done by a qualified security assessor (QSA) or allow clients to request on-demand assessments. If the service provider chooses to provide a QSA assessment, you need to make sure that it covers your compliance needs and is part of the contract.

How ZenGRC can ease the burden of PCI DSS compliance

With ZenGRC, organizations can rapidly deploy a governance system that provides easy-to-read insights. For example, our PCI DSS compliance dashboard allows organizations to review control health at a glance while also listing critical issues facing the organization.

ZenGRC’s ongoing monitoring abilities provide updated, in-the-moment insights enabling organizations to continually respond to changing threats and vulnerabilities in a continuously evolving threat environment. Moreover, organizations can store their penetration test and audit findings on the ZenGRC platform to help enable better cross-enterprise outcomes.

To read about how scoping your PCI DSS compliance can help you better manage your compliance needs, download our ebook, PCI-DSS: Steps to Successful Scoping.

Regulatory Compliance in Healthcare Organizations

ZenGRC Team · April 3, 2018 ·

2017 acted as a call to action for those in the healthcare industry. Patient Health Information (PHI) incorporates everything hackers need to steal identities and compromise an organization’s reputation. Therefore, protecting PHI, and more importantly, electronic patient health information (ePHI) means that healthcare organizations need to be more diligent ensuring that their daily compliance activities match their policies.

Healthcare Regulatory Compliance

What Regulatory Compliance Requirements Affect Healthcare

Although the Health Insurance Portability and Accountability Act (HIPAA) gets the most screen time, organizations involved in healthcare need to incorporate the Health Information Technology for Economic and Clinical Health Act( HITECH) compliance as well. Although interrelated, 2009’s HITECH specifically intended to promote information technology while protecting privacy and security concerns regarding ePHI.

HITECH modified not only HIPAA but also the Social Security Act. Thus, understanding how the different regulatory compliance puzzle pieces fit together became more difficult.

How HIPAA and HITECH Are Similar

The Health and Human Services Department (HHS) oversees both HIPAA and HITECH compliance.

Healthcare organizations most often focus on HIPAA compliance because it established the Privacy Rule setting national standards regarding medical record and PHI protection. Since the Privacy Rule’s adoption in 2000, HHS made only one modification 2002 thus establishing it as one of the first information security and privacy regulations.

The Office of the National Coordinator for Health Information Technology (ONC) promotes healthcare quality by promoting health IT and establishing guidelines for electronic health records (EHRs) and securing ePHI to protect privacy.

Thus, while HIPAA and HITECH integrate with one another, they come with distinct foci. HIPAA focuses on protecting privacy and expands beyond information systems. Meanwhile. HITECH focuses specifically on information technology and preserving electronic information.

How HIPAA and HITECH Differ

While HIPAA and HITECH have many similarities, they also differ on several important details.

Although HITECH extended HIPAA, HIPAA remains focused on breach notification and privacy to protect against fraud and identity theft.

Meanwhile, HITECH distinguishes itself from HIPAA since it created restructured civil and criminal compliance penalties. Moreover, it extended the breach notifications requirement beyond covered entities and incorporated business associates.
Finally, from an information technology perspective, compliance managers should focus on the importance of effective encryption. Even should a malicious actor breach the ePHI, effective encryption mitigates rule violations. Thus, if the encryption effectively makes the information unreadable, the organization breached may not be fined.

However, proving effective encryption additionally means being in compliance with the NIST Federal Information Process Standard. Thus, healthcare regulatory compliance requires understanding your organization’s IT architecture.

How HITECH’s Compliance of Medicare and Medicaid Impact HIPAA Business Associates

Understanding healthcare regulatory compliance requires understanding overlaps between business associates, their information, and how that can impact the overall supply chain.

The definition of Business Associate incorporates and person or entity not covered entity’s workforce member who provides services to or performs functions or activities for a covered entity.

Traditionally, the Omnibus Rule’s definition of Business Associate brings healthcare management companies, healthcare plans, and healthcare payment organizations under the arc of HIPAA and HITECH. However, for those working with Medicaid, additional services may be incorporated under these compliance requirements.
For example, HITECH and HIPAA consider Medicaid’s Non-Emergency Medical Transportation (NEMT) to be a Business Associate under the Omnibus Rule. Thus, despite being nothing more than a network of transportation brokers, information collected remains subject to these healthcare regulations.

Thus, organizations need to determine their location in the supply chain to ensure no HIPAA or HITRUST violations as well as to decide whether or not they want to assume the regulatory compliance risk if they choose to scale.

What the Board of Directors Needs to Know

Organizations looking to shift into the healthcare sector need to ensure that their Board recognizes the compliance implications. Providing the appropriate level of Board oversight requires visibility into both the healthcare landscape as well as the organization’s current compliance environment. Moreover, should an organization decide to incorporate healthcare providers or their vendors as part of its business plan, the Board of Directors needs to understand how they fit into that supply chain.

Under HIPAA, vendor risk creates corporate risk. Thus, whether your company sits at the top of the supply chain, in the middle, or at the bottom, any interaction with HIPAA regulated entities means you need to be compliant also.

Thinking about HIPAA and HITECH violations as dominoes in a row, if one domino falls so do all the others. Thus, vendor management’s importance may increase if you decide to expand into the healthcare industry.

How Automation Eases the Healthcare Regulatory Compliance Burden

ZenGRC’s SaaS platform enables organizations to visualize compliance gaps. Regulatory compliance no longer needs to act as a barrier to new markets. As you map controls to a particular standard or framework, ZenGRC allows you to assign that control to other standards or frameworks that it satisfies.

The first step for successful implementation of the Health Information Trust Alliance Cybersecurity Framework (HITRUST CSF) is to engage in a CSF Self-Assessment with the help of a CSF assessor. CSF assessors are consulting firms that HITRUST approved to perform the assessment. Using this information, you can gauge your system and regulatory requirements to help determine your risk and scope.
For example, an organization currently ISO 27001 compliant may be using a firewall. If you choose to incorporate PCI DSS compliance, a firewall is also an accepted control. Assuming that you want to expand to acting as a healthcare provider payment processor, you need to determine whether this control maps to HIPAA and HITECH compliance.

Once you set up your controls in ZenGRC, it automatically maps current controls to new standards as you add them. This means that your ISO 27001 controls will be mapped to your new PCI DSS compliance framework. All you need to do now is determine what additional controls you need to incorporate.

The HHS Office of the Inspector General (OIG) offers a guideline that discusses all the parties involved in your compliance efforts, from your employees to your Board of Directors. Automation helps you better communicate with your organization’s various stakeholders, providing them with the right information for their needs.
A HIPAA compliance audit is similar in that an audit management software that provides a single source of truth can help you save time. Saving time saves money because your employees can focus on securing your environment.

With an automation tool like ZenGRC, you can monitor your compliance while storing all your necessary documentation in one place.

ZenGRC’s compliance management software provides a risk dashboard that gives insight into the effectiveness of your ongoing monitoring so that you can meet internal audit standards.

Not only does this simplify incorporating new standards into your overall landscape, but it also means that you can expand your business into revenue streams that seemed too onerous before.