Setting Up IAM: Managing Permissions to Ensure Compliance

One of the biggest issues for many companies is ensuring compliance. This work becomes easier with identity and access management (IAM) software. IAM allows administrators to specify strict access protocols to control which networks and resources users can use and how they can use them. In short, the software provides visibility into and governance over what employees can and cannot do.

Let's look closely at four different compliance requirements—SOX, HIPAA, HITECH, and PCI—to evaluate how IAM simplifies compliance.

SOX

In 2002, following financial scandals, the Sarbanes-Oxley Act, called Sarbox or SOX for short, was enacted into law. Its aim was to improve investor confidence by making corporate practices more transparent. Among others, requirements include measures for:

  • policy enforcement
  • risk assessment
  • fraud reduction
  • compliance auditing

A major purpose of SOX is to make corporate financial statements more reliable. The Act provides for civil and criminal penalties for noncompliance, so heeding it is very important.

IT is obviously crucial for SOX. After all, most of the data making up corporate financial statements is created by information technology systems. But IAM in particular can support Sarbanes-Oxley compliance. 

For instance, IAM can alter user access rights precisely when job duties change. If an employee changes position and his or her network access isn't re-adjusted to suit the new role, compliance risk increases for the business, as segregation of duties (SoD) violations might occur. But with IAM, surgical changes in access are quite possible. A similar example would be terminating access after an employee leaves the firm.

HIPAA

HIPAA, the Health Insurance Portability and Accountability Act, was enacted in 1996. One of its goals was to establish national standards governing the privacy of protected health information. Among other functions, the law is intended to strike a balance between individual needs for privacy and the need for medical professionals to share health information to safeguard the patient and the public. Readers may be familiar with consent forms and other documents deriving partially from HIPAA standards.

IAM can make it much easier for organisations to ensure HIPAA compliance. For example, identities based on informed consent categories, such as those who have opted in versus those who have opted out, may be enforced strongly. If a patient opts out of sharing information from one medical professional with another, the organisation can be confident the latter professional will be denied access to the restricted data.

IAM can also implement policies like that across a wide span of diverse systems. That reassures executives that compliance will take place despite the variety of information technology in use. Okta’s HIPAA-compliant cell is specifically designed to meet HIPAA requirements for service providers.

HITECH

The Health Information Technology for Economic and Clinical Health Act (HITECH) is often discussed in the same breath as HIPAA, but it is a different set of requirements. HITECH was enacted into law in 2009 as part of the economic stimulus bill. One of its purposes was launching public investment in a nationwide network of electronic health records (EHRs). 

Among other measures, HITECH mandates federal breach notification for stored health information that is not encrypted. In addition, HITECH extended certain HIPAA requirements beyond entities that were covered in the past—payors, providers, and clearinghouses—to their business partners.

What does all this mean for IAM? One advantage IAM offers here is that the software can supply identity federation. Access doesn't have to exist only within a single organisation; it can be federated outside the boundaries of an organisation to permit secure access to electronic health records by more than one group. This helps with HITECH's extended requirements.

PCI

PCI is short for PCI DSS, or the Payment Card Industry Data Security Standard. Unlike the above compliance standards, PCI does not arise from government law. It is a proprietary information security standard for companies that manage major credit cards. Full compliance means companies encrypt payment card data in transmission, submit to penetration testing, and more. PCI does not mandate specific technologies, but explains industry best practices.

IAM software can help achieve PCI compliance by maintaining the privacy of payment card data. For instance, there are certain PCI requirements about limiting the number of employees who can access payment card data to the absolute minimum who need to know this information. And of course, IAM shines here. It can ensure, for example, that privileged users are granted only the fewest privileges necessary to complete their work. That prevents unnecessary escalations of privilege that can result in privacy violations.

IAM for Compliance

Whether your organisation needs to ensure compliance with any of the four regulations described above or with other standards specific to your industry, identity and access management solutions can simplify the task by providing better governance over users' identity and what they can and cannot access on the organisation's networks. Okta maintains secure, audited infrastructure and processes that keep our service highly secure and available to assist in your compliance initiatives.