Have you heard one about the bear and the two hikers?

A bear jumps out of the bush and starts chasing two hikers. They both start running for their lives, but then one of them stops to put on his running shoes.

The first hiker says, “What are you doing? You can’t outrun a bear!”

The second hiker replies, “I don’t have to outrun the bear; I only have to outrun you!”

Compliance works in a similar way. You don’t need to be the most compliant company; you just need to meet the requirements well enough to satisfy regulators, auditors, customers, and stakeholders. And, ideally, you want to be more compliant than your competitors. That’s how you outrun the bear (err… win the customer.)

That’s not to say that meeting even the minimum of compliance standards is easy; far from it. But it’s good to know just how much you need to do when it comes to compliance, so you don’t make yourself go nuts in the process.

Here’s our advice on how to meet compliance without losing your mind.

Step One: Understand the Role of Compliance

A major reason to achieve compliance is to win and keep business. Achieving compliance will not automatically make your business more secure, and it likely won’t magically solve any other problems. But with HIPAA, for example, being compliant means you can work with protected health information (PHI), which in turn means you can do business as or with healthcare providers, insurance companies, and anyone else who handles PHI.

Likewise, being PCI DSS compliant means you can process and handle credit card transactions and related data. Those are two major business avenues that you may want — or even need — to keep open in order to be successful.

We often work with startups that are on the verge of a big sale (maybe their first big sale) and are nervous about having those big compliance conversations with their customers. What should they expect? What policies do they need to have in place? How do they tell a cohesive story about their compliance readiness?

Step Two: Understand Compliance Requirements

Regardless of which requirements you are beholden to, you must understand exactly what those requirements entail.

Here are two questions to ask yourself when going through a long list of compliance checkboxes:

  • What’s the actual question I am trying to answer?
  • What am I trying to solve for?

These are particularly important questions to ask when it comes to compliance requirements that are more gray than black-and-white. For example, when it comes to PCI compliance, one of the mandates is to “Identify and authenticate access to system components.” Specifically, this requires companies to:

  • Assign all users a unique ID before allowing them to access system components or cardholder data
  • Control the addition, deletion, and modification of user IDs, credentials, and other identifier objects
  • Immediately revoke access for any terminated users


The questions you are trying to answer here are:

  • Do you know exactly who is using your systems?
  • Can you add/delete users at a moment’s notice?

And the underlying problem you’re trying to solve for is identity and access management, so you need a tool that can help you do this.

It’s worth spending the time to understand exactly what compliance mandates are asking of you, and what that means for your particular business, so that you allocate resources toward answering the right questions and solving for the right problems.

Step Three: Be Proactive About Compliance

There is no magic bullet when it comes to compliance. However, the more proactive you can be about it — and the sooner you can do so — the more likely you are to be able to meet compliance requirements, achieve related business objectives, and stay sane in the process. In other words, don’t wait until the very last minute.

This means proactively implementing processes and procedures that support compliance requirements. It also means purchasing technology that can help you achieve compliance beyond the processes and procedures. The following table shows select PCI requirements that can be addressed by a comprehensive cloud-based security platform.

PCI DSS Requirements


Requirement 6. Develop and maintain secure systems and applications

6.1 Establish a process to identify security vulnerabilities, using reputable outside sources, and assign a risk ranking (e.g. “high,”“medium,” or “low”) to newly discovered security vulnerabilities.

6.2 Protect all system components and software from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

Requirement 7: Restrict access to cardholder data by business need-to-know

7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.

7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

Requirement 8: Identify and authenticate access to system components

8.1 Define and implement policies and procedures to ensure proper user identification management for users and administrators on all system components. Assign all users a unique user name before allowing them to access system components or cardholder data.

8.2 Employ at least one of these to authenticate all users: something you know, such as a password or passphrase; something you have, such as a token device or smart card; or something you are, such as a biometric. Use strong authentication methods and render all passwords/passphrases unreadable during transmission and storage using strong cryptography.

8.3 Secure all individual non-console administrative access and all remote access to the cardholder data environment using multi-factor authentication. This requires at least two of the three authentication methods described in 8.2 are used for authentication. Using one factor twice (e.g. using two separate passwords) is not considered multi-factor authentication. This requirement applies to administrative personnel with non-console access to the CDE from within the entity’s network, and all remote network access (including for users, administrators, and third-parties) originating from outside the entity’s network.

8.7 All access to any database containing cardholder data must be restricted: all user access must be through programmatic methods; only database administrators can have direct or query access; and application IDs for database applications can only be used by the applications (and not by users or non-application processes).

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

10.1 Implement audit trails to link all access to system components to each individual user.

10.2 Implement automated audit trails for all system components for reconstructing these events: all individual user accesses to cardholder data; all actions taken by any individual with root or administrative privileges; access to all audit trails; invalid logical access attempts; use of and changes to identification and authentication mechanisms (including creation of new accounts, elevation of privileges), and all changes, additions, deletions to accounts with root or administrative privileges; initialization, stopping or pausing of the audit logs; creation and deletion of system-level objects.

10.3 Record audit trail entries for all system components for each event, including at a minimum: user identification, type of event, date and time, success or failure indication, origination of event, and identity or name of affected data, system component or resource.

10.4 Using time synchronization technology, synchronize all critical system clocks and times and implement controls for acquiring, distributing, and storing time.

10.5 Secure audit trails so they cannot be altered.

10.6 Review logs and security events for all system components to identify anomalies or suspicious activity. Perform critical log reviews at least daily.

10.7 Retain audit trail history for at least one year; at least three months of history must be immediately available for analysis.

10.8 Service providers must implement a process for timely detection and reporting of failures of critical security control systems.

10.9 Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

Requirement 11. Regularly test security systems and processes

11.4 Use network intrusion detection and/or intrusion prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points inside of the cardholder data environment, and alert personnel to suspected compromises. IDS/IPS engines, baselines, and signatures must be kept up to date.

You may want to bring in a third party to do a compliance assessment and risk analysis before you get started. Just make sure to explain that you are not looking to become the most compliant company in the history of business. You just want to be more compliant than your competitors.

Step Four: Don’t Go Too Far

One requirement within PCI DSS states that businesses must, “change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.”

Passwords are important, of course, and PCI DSS provides some specific guidance around how to go about changing those default passwords and making sure that this has been done comprehensively across systems.

However, PCI DSS doesn’t specify how to make sure that new passwords are secure. While it’s a very good idea — especially at larger companies — to build a password security policy and possibly even implement an identity management and/or SSO program, you should recognize that this is not required by PCI DSS. So if your goal is to check the PCI boxes so you can meet a business objective, don’t get sidetracked with password security or identity management. Change the defaults and move forward.

To be clear, we are not suggesting that you skip over procedures and policies that can help your organization be more secure. In the preceding example, you’ll want to revisit the question of password security after getting through compliance. But we recommend that you understand to the letter what compliance actually demands, so that you can prioritize any updates or changes you need to make and achieve compliance in a timely and efficient manner.

The Takeaway

Learn when enough is enough. Your auditor or risk assessment firm should be able to tell you when enough is enough, but keep in mind that these firms often profit from the remediation process, so they may have an incentive to push beyond the “good enough” mark.

Be sure to communicate clearly and early that your goal is to achieve compliance and move forward. You can always spend more time later making sure your systems are airtight when it comes to security, but when it comes to compliance, done is better than perfect. Done is the holy grail.

Compliance Playbook

The Threat Stack Compliance Playbook for Cloud Infrastructure is now available!

The Playbook is intended for readers who want to understand what’s involved in becoming compliant in a cloud environment — without getting caught up in the details and complexity that the compliance process is well known for.

Download the free Playbook now!