Compliance Controls Best Practices

It’s often challenging to determine which of your organization’s IT assets are at risk and what controls to implement to protect them. Companies—from startups to large enterprises—must adhere to requirements stemming not only from internal needs but also from various standards, regulations, and frameworks to ensure security and compliance.

With thousands of potential requirements, there are best practices that can help ensure a simplified approach while navigating the design and implementation of compliance controls. This applies whether your company’s environment is fully cloud-native, on-premises, or a mix of both.

This article illustrates eight best practices that prepare you for effective control implementation, not just for compliance purposes but also for your organization’s overall security and resilience.

Summary of key best practices for compliance controls

Know your information assets

To know how to protect with compliance controls, you first must know what to protect. The “what” represents company assets. Knowing what these are and having them managed is foundational to applying protective controls. In fact, having an information/IT asset inventory is a very common compliance control in itself. 

Creating the inventory can be a complex undertaking, implying the need for the following:

• Defining what an asset is to your organization and what the scope of the inventory will be. You might leave out short-lived assets, such as some virtual machines. A good idea is to create abstractions for asset clusters that serve the same purpose. You can also define asset categories, such as “network equipment,” which would enable you to create relations between underlying assets and define a criticality for the asset category directly. 
• Establishing the key attributes of the IT asset that you need to record. Your asset inventory might need a wide array of attributes, such as location, classification, version, supported business process, lifecycle status, recovery time objective (RTO), data retention, and so on. Some of these attributes are explicitly demanded by regulations.
• Determining how to obtain these attributes from different data sources. An asset inventory implementation effort depends on the maturity of your organization and the tools in use. Some common challenges are bringing together all data sources that you need along with the attributes required. For example, the criticality of assets might be found in an Excel-based business impact analysis (BIA), physical assets could perhaps be noted in a building manager’s security plans, configurations may be in AWS Manager, etc.

Ideally, your inventory should be centralized and updated without manual intervention to add new entries, run a query on other inventories, or permanent data quality checks (does “missing asset owner” sound familiar?). Device42’s solutions for IT asset management and discovery optimize the implementation of this key compliance control.

Pro-tip: Auditors will 100% ask about your IT asset inventory and will not overlook a missing one.

Information Assets (source)

Conduct a vulnerability assessment and look at threat scenarios

Once your assets are known, you need to determine their weaknesses or where they may be inherently vulnerable to exploits. Bear in mind that a vulnerability assessment is not limited to software vulnerabilities:

• People, probably one of your most important assets, are vulnerable to social engineering. 
• Software is vulnerable to attacks, misconfigurations, and unauthorized access.
• Hardware can be affected by sabotage, theft, or environmental conditions.

To help you identify vulnerabilities, you can look at a variety of information, such as penetration tests, audit reports, or incidents that have occurred. If none of these are available, use public data combined with the professional judgment of security, IT, and risk stakeholders.

The next step in this risk assessment exercise is to determine what threats could impact your assets. Threats can be natural, technological, or human-made; the table below outlines some examples.

Focus on plausible scenarios that could affect your business. If your infrastructure is hosted on the cloud, one of your scenarios should be “CSP downtime.” Think about what assets are vulnerable to this scenario and what can you plan to minimize the potential impact of this risk scenario materializing. Your risk assessment should capture this type of information.

Determine risks

Now that you have the data on assets, vulnerabilities, and threats, you can determine the risks that could impact your organization. A common way to do this is to use the following formula:

Risk = Asset x Vulnerability x Threat

Example: What would happen if our customer database (asset) is unauthorizedly accessed (vulnerability) by a disgruntled employee (threat) and disclosed outside of your organization (risk)? Here, your risk can be defined as “critical data exfiltration by insider threat.” 

You should assess each determined risk’s likelihood and impact, considering that there are no controls applied. This will help you obtain a real image of your inherent risks, so you can rank them and understand where your priorities should be when it comes to applying controls.

5×5 Risk Matrix Example (source)

Compromised compliance equals, in many cases, compromised security. Ultimately, security risks boil down to the compromise of the three security properties: 

• Availability: If your core systems are unavailable and you are in the retail, financial, or public infrastructure sector, every second can be critical to your business’s survival.
• Integrity: If you are a publicly traded company and your financial reports are inaccurate, you are breaching SOX compliance.
• Confidentiality: Data breaches violate regulations such as the GDPR and US privacy laws, and they can cause a crippling hit on reputation and costs.

Map controls to the relevant frameworks

If you’re in an industry subject to stringent regulations, it’s a good idea to create a mapping of all the requirements that come from them. If you’re unsure which compliance standards apply to you, it’s best to learn this as early as possible so you can be prepared with a control framework that satisfies all requirements.

The good news is that many of them will overlap. Controls related to the management of asset inventory, accesses, changes, vulnerabilities, or incidents are found in most standards, best practices, and regulations in different forms. Different forms are what make… well, the difference. Let’s look at one of them.

“Management reporting” is a common control in the context of security compliance: You need to inform upper management about the performance and health of the security measures. According to SOC 2, this needs to be done regularly, while ISO 27001 suggests it be done annually. The EU Digital Operational Resilience Act (DORA) also wants it annually and says it needs to include a risk assessment. Finally, the financial German regulator, BaFin, specifically asks for management reporting to be done quarterly.

The takeaway? Make sure you thoroughly assess all requirements. If you comply with the most stringent one, you’re safe with the rest.

Use a mix of preventive, detective, and corrective controls

Compliance controls can be of three types: preventive, detective, and recovery. These seem pretty self-explanatory, but let’s delve into some examples.

Let’s say you have identified a risk of data exfiltration through vulnerability exploitation in one of your client-facing applications. Let’s also assume that this occurs through a ransomware attack. What controls can you apply?

• Preventive controls to discourage or block malicious behavior: You want to have preventive controls as a first layer of protection. Some of these can be access controls (logical and physical), secure authentication of humans and systems, acceptable use policies, intrusion prevention systems (IDS) such as firewalls, data leakage prevention, incident management planning, regular patching, secure coding practices, security awareness, and third-party assessments.
• Detective controls kick in when deviations are recorded: Think of endpoint and network intrusion detection systems (IDS), log monitoring and alerts, and the good old CCTV.
• When all else fails, corrective controls are applied: These involve retrieving data from backups and activating business continuity and disaster recovery plans. 

Types of Controls (source)

By using a mix of these, you are applying layered security, which is instrumental when dealing with your identified risks. Considering a ransomware scenario, we can easily see that most controls should be preventive in nature: The attacker should not be able to get into the environment. But if one of these controls fails, detective and corrective controls are the second and third layers in your defense, helping to detect the intrusion early or at least to recover locked data.

Align on implementation requirements

Designing the right controls to protect assets and formalizing these controls in internal policies is quite an effort. However, making them operational and effective is usually even more time-consuming and resource-consuming. The teams operating these controls should ideally be consulted from the control design phase to ensure that each control makes sense and is feasible and that no critical aspects have been overlooked.

For instance, suppose you have determined that identity and access management (IAM) is a key control to protect your assets. Your IAM team is instrumental in implementing this control’s requirements, and they might need to bring to your attention several factors, such as:

• The layers where access controls need to be applied and what should be the strength for each (e.g., MFA for domain access and sensitive applications)
• Password security requirements, such as length, frequency of change, and policy for potentially compromised accounts
• How often should access be recertified for each asset type or criticality, and if there are manual aspects of it that carry some risk
• Physical access management for equipment hosted in third-party locations
• A dependency on the IT asset inventory; if the inventory is incomplete, not all assets are captured in the IAM policies
• Tools that need to be developed or purchased to meet IAM requirements.

No matter how well a control is explained on paper, the job is not done here. Compliance controls should be discussed in a timely way with all relevant stakeholders to set the ground for an effective implementation.

Test controls

You should have an internal control testing process as part of an effective risk management framework. This helps your organization identify control deficiencies before they are caught by external audits or, even worse, failures occur in a real-life incident.

You can set this up according to your needs. For instance, you can test operational effectiveness for key controls and design effectiveness for the rest. You can use audit best practices to choose samples, and you can leverage automation to obtain evidence (e.g., reports from vulnerability scans). 

Here are some high-level examples of what you could test as part of this process.

Iterate, amend, and improve

At this point, your audits should not create too many surprises, but your goal should be to apply controls that truly add value to the organization’s security posture. Go beyond compliance: Organizations that see compliance controls just as a checklist exercise cannot rest assured that their assets are continuously secured, that loopholes are discovered, and that potential incidents will be managed properly. 

It’s safe to say that the work is never done with compliance controls. New risks can be identified every day through internal reporting, new product developments, threat intelligence, recurring incidents, third-party compromises, and business changes. All these are indicators of potential new vulnerabilities that can be treated with new or amended controls.

The world’s most sophisticated asset discovery and dependency for compliance and audit

Learn More

Discover assets automatically including hardware, software, and cloud infrastructure

Visualize application dependencies

Meet your compliance and audit requirements comprehensively and confidently

Last thoughts

Truthfully, there is no way around compliance controls. Compromised compliance can lead to regulatory fines, increased scrutiny, and license bans, which ultimately lead to a damaged reputation and loss of business revenue. However, organizations that put effort into good compliance and security practices and manage their risks in a mature way will always make a good impression on customers, regulators, and other stakeholders.

Device42 can help you start implementing compliance controls by resolving a critical prerequisite: having a comprehensive, up-to-date IT asset inventory. Through product features like cloud discovery and infrastructure discovery, you can have a complete inventory of your cloud environment, on-premise servers, and network devices. 

With automated discovery, grouping, and dependency mapping, you get a full picture of your assets, enabling you to apply further security controls.