*This webinar was recorded live on November 16, 2023. Since this recording, Covalence has been renamed to Field Effect MDR.
Compliance is challenging. Understanding and responding to regulatory checklists can be time-consuming and stressful. The good news is that Field Effect MDR helps you achieve and maintain compliance as you navigate the complexities of the regulatory landscape.
Watch this webinar recording to hear from Matt Lewis, Field Effect's CSO, as he talks about:
In a nutshell, technical compliance is all about the norms, standards, and rules tied to the CIA triad: confidentiality, integrity, and availability of data. Most compliance frameworks either refer directly to CIA or circle around it in their own way.
Confidentiality means the data belongs to you—no one has stolen it, and no one without authorization can see it. Integrity ensures the data hasn’t been changed and that people can trust the information is accurate. Availability means the data is accessible to the right people at the right time.
Compliance frameworks handle auditing in two different ways. Some are completely voluntary, while others require an outside audit from a third party who verifies that the standards are being met.
For a variety of reasons we’ll explore, technical compliance is often challenging. It can be stressful for organizations to implement, but understanding these basics is the first step toward making it manageable.
Let’s look briefly at a couple of technical compliance frameworks. I’ve organized these in a specific way, starting with PCI DSS and CMMC (Cybersecurity Maturity Model Certification), which is the upcoming certification due to be released next year. It’s going to mandate certain cybersecurity rules and frameworks for everyone who wants to sell into the United States military system or be part of the defense industrial base.
The reason I start with these two is because they’re really not voluntary. If you want to work with credit card information and you haven’t outsourced it to a third-party payment company, you’ll have to follow PCI DSS. Likewise, if you want to sell into the defense industrial base and offer your products and services to the U.S. military, you’ll most likely need to meet CMMC requirements next year. Both of these frameworks are audited by a third party.
Next is HIPAA. This one is also not voluntary—if you want to handle electronic public health information, you must comply with HIPAA rules. However, the HIPAA standards don’t actually require a third-party audit, so it’s mandatory but not audited.
Then we get into ISO 27001 and SOC 2. These are voluntary frameworks, but they do require an external third-party audit. So you can see there’s a mix: some mandatory and audited, some mandatory but not audited, and some voluntary but audited.
Finally, we have the CIS Controls. This is a great example of a framework that’s voluntary and doesn’t require any third-party audit.
There are many benefits to compliance. First and foremost, it provides structure, boundaries, and rules, giving us a way to improve our information security. That’s the biggest one—when you have a clear baseline to follow, it becomes much easier to strengthen your networks and prove that those improvements are happening.
Some organizations will also need to adopt a framework in order to qualify for insurance. Cyber insurance is becoming increasingly difficult to obtain, and being able to demonstrate a technical compliance framework can make all the difference.
Compliance can also open new market opportunities. A good example is CMMC: if you’re a manufacturer and want to sell into the U.S. defense industrial base, certification can directly increase your revenue.
Another benefit is that compliance smooths business-to-business transactions. That’s one reason why we at Field Effect became ISO 27001 certified. When customers use your products and services and trust you with their data, they want to know it will remain confidential, available, and accurate. A recognized certification builds that trust and makes transactions easier.
Finally, compliance can help limit legal liability. If the worst happens and the data you hold is stolen or ransomed, you can point to your frameworks to show that you did everything possible to prevent it. That proof of diligence shows you weren’t negligent, offering peace of mind and reducing legal risk.
The short answer is no, it doesn’t. However, many Canadian companies will still need to pursue CMMC because Canada’s defense industry is so closely tied to the U.S. military. Canadian manufacturers often sell into both markets, and there’s also a very real chance that the Canadian government may adopt a similar requirement in the future.
Compliance can feel intimidating for a number of reasons. The first is that it’s often a big lift. When you compare a framework to what you’re currently doing, you’ll likely uncover many areas that need improvement—and probably some where nothing is in place at all. That initial gap can feel overwhelming.
There are also financial implications. Implementing a framework costs money, but not doing so can cost you opportunities and revenue. What makes it even harder is that the ROI isn’t always clear. If you invest $100,000 in compliance, when and how will you see that money come back? That uncertainty adds to the fear.
Another factor is subjectivity. Compliance frameworks are long, often vague documents. They don’t spell things out with simple instructions like, “Do A, B, and C and you’re good.” Instead, they use broad language that must be interpreted. That’s by design—standards have to apply to many different types of companies and networks. They won’t say “run a Fortinet firewall.” Instead, they’ll talk about monitoring networks or addressing vulnerabilities, leaving it up to you to turn those requirements into specific, actionable steps.
Finally, there’s a sense of lost control—especially with audited frameworks. You can do everything you believe is necessary to meet a requirement, but at the end of the day, the only opinion that matters is the auditor’s. That can leave you feeling like, “I’ve done everything I can, but I’m not fully in control of the outcome.”
So how do you choose which technical compliance framework is right for your business? Sometimes the answer is obvious. If you’re dealing with health records in the United States, you’ll need to comply with HIPAA. If you want to sell products or services to the U.S. military, CMMC applies. In those cases, the path is clear.
Other times, the decision comes down to budget. If your customers aren’t asking for a SOC 2 report and they’re not asking whether you’re ISO 27001 certified, it may be best to avoid frameworks that require third-party auditing—they can be very expensive. Instead, you can get many of the same benefits by adopting a voluntary, non-audited framework, such as the CIS Controls from the Center for Internet Security or NIST’s Cybersecurity Framework, which is voluntary, not audited, and free. That said, if customers frequently request a SOC 2 report, then it may make business sense to pursue it.
When in doubt, consult an expert. There are plenty of people who love to talk about compliance—we’ve got them at our company—so don’t hesitate to reach out for guidance.
One final point: the first framework you implement will always be the hardest. Fortunately, there are many commonalities across frameworks. In fact, most people say there’s an 85–90% overlap between getting a SOC 2 Type II report and being ISO 27001 certified. That’s how much common ground exists. Let’s take a look at some of those overlaps now.
The first is endpoint monitoring. Almost every technical compliance framework says something about monitoring for cyber threats on the endpoint. That could be through antivirus software or through something more sophisticated like EDR or MDR, such as Field Effect MDR.
A common question is whether basic, legacy antivirus can meet requirements. The answer is: probably, yes—if you’re aiming for the bare minimum. There are many reasons not to rely solely on legacy antivirus, but if your goal is only to meet minimum requirements, you can likely get by as long as you’re running it on all systems, it’s regularly updated, and it can detect known threats.
The next area is vulnerability monitoring—and this is where legacy antivirus alone will struggle. Most frameworks use language like continuous, meaning monitoring should be happening all the time. You should be looking for threats on your networks and also for vulnerabilities—unpatched or legacy software, things like that—and incorporating threat intelligence.
That means you have a team, or an outsourced team, constantly scanning for new vulnerabilities, watching vendor product notices, and turning that information into active searches for new threats on your network. That’s very difficult to do in-house unless you’re a very large enterprise.
Finally, most frameworks look for policy. There should be a documented policy that shows how your organization monitors and addresses vulnerabilities within a specific timeframe.
Network monitoring—I wouldn’t say this is ubiquitous across all technical compliance frameworks, but many either call it out directly or mention it tangentially, like PCI DSS and HIPAA. What they’re looking for is traffic monitoring: that you’re examining your network traffic and using it to feed your vulnerability analysis. It’s another way to spot issues on your network.
A common question is whether you can get away with just a legacy firewall—or maybe a next-generation firewall—to meet network monitoring requirements. It really depends on the hardware and how you’re using it.
To confidently check that box for a voluntary standard, or to satisfy a third-party auditor, you’ll want to show it’s not just plugged in and forgotten. It should be part of a larger ecosystem: someone is reviewing logs, alerts from the firewall are being triaged, and there’s an ongoing process behind it. Auditors will want to see more than a device running unattended—and you’ll likely want more than that to be confident.
Cloud monitoring is the new kid on the block. For context: the 2013 version of the ISO standard didn’t mention “cloud” at all; the 2022 version mentions cloud and cloud monitoring over a hundred times.
What frameworks look for is similar to network monitoring: continuous monitoring, evidence that you generate alerts when cloud security incidents occur, and proof your organization can detect and respond to those incidents.
Logging is another big one—almost every technical compliance framework talks about it. They want an audit trail: something an auditor or your organization can go back to if there’s an issue with confidentiality, integrity, or availability. Most frameworks also look for anomaly detection—the ability to use those logs to spot unusual activity.
Access controls are huge here: generally, logs shouldn’t stay only on the server or workstation where they can be altered. Move them off the device as quickly as possible to a location with very limited access.
Retention matters too. How long you keep logs depends on the standard. Some don’t specify a timeframe; others have rigid requirements—four, five, six years, etc. If the standard doesn’t specify, auditors will expect to see a logging and auditing policy that states your retention period—and evidence that you follow it.
That’s a good segue into something technology alone can’t solve: policies. Every compliance framework talks about them, and they’re a necessary evil because, without policies, there’s no audit criteria.
For example, with logging: if I’m an auditor and I see some servers keeping logs for one year, some for two, some for three, how do I know what’s correct? Without a documented policy, I can’t tell which is right—maybe none of them are.
I would have to look at your logging policy—what you’ve stated you’re going to do. When you have those policies, you now have audit criteria. You have a baseline that outlines what your organization believes in and how you’re going to run things.
If compliance frameworks mention policies, they’re also likely to require updating them periodically. It’s not enough to write an audit or logging policy once and let it collect dust for ten years. You need to use it, update it, and show that it’s an active part of your security and compliance ecosystem.
I wrote all the policies for Field Effect, so if you’re writing one right now, I feel for you.
Physical security is another area that’s nearly universal across frameworks. The reason is pretty simple: it doesn’t matter how good your network security is—whether you’re running Covalence or have the latest and greatest tools—if I can just walk into your data center and steal a server, or walk out of your office with the CEO’s laptop, your confidentiality is compromised.
So frameworks talk about physical controls. These can include basics like locks on doors, fobs so only employees can enter, or even how equipment is positioned (for example, monitors shouldn’t face a street-facing window where anyone passing by could see sensitive information).
They also look for a layered approach. You might have a public reception area at the front of your building, but employees need to fob into the working area, and only select staff should have access to the server room. That should align with your organization’s rules-based access policies.
Physical security may seem basic, but it’s essential.
With all that in mind—and the commonalities we’ve discussed—what’s the right solution from a technology perspective to meet compliance goals? Ideally, it should provide holistic coverage across endpoints, networks, and the cloud. It should support vulnerability detection, log retention, and offer insights into compliance, helping you spot gaps in your program. And it should be backed by a strong team.
Fortunately, there is a solution like that: Field Effect MDR.
With holistic monitoring, as soon as you install Field Effect MDR and start receiving our proprietary reporting—Actions, Recommendations, and Observations known as (AROs)—you’ll immediately see coverage at the host, network, and cloud levels. You’ll also have the evidence you need to demonstrate compliance to external auditors.
Next is vulnerability detection. What makes Field Effect MDR unique is that it not only protects against malware, but it continuously identifies vulnerabilities at the host, network, and cloud levels, 24/7. Our threat intelligence team monitors vendor notifications and new CVEs, assessing risks to ensure none of our clients are impacted. When necessary, we rapidly report findings to you.
Field Effect MDR also provides an endpoint view, so you can see vulnerabilities detected on individual hosts in real time. This is exactly what auditors and frameworks want: continuous monitoring, powered by threat intelligence, with evidence that you’re addressing issues.
Finally, log retention. This is a new, cloud-based feature in Field Effect MDR. If retention requirements extend beyond 90 days, your logs are securely transitioned from your network into our cloud environment, where they remain safe.
We also offer flexible retention options. You can choose to keep logs for one year, four years, five years—whatever your requirements, just let us know. Another benefit is our low flat-rate pricing. Many providers charge by the gigabyte, which can quickly add up. With us, you’ll have one flat rate without getting nickeled and dimed for every log stored.
The next important capability for a strong compliance solution is insights. We’re actively developing this. Recently, we released our ISO 27001:2022 mapping. What this means is that every ARO you receive will include links back to the ISO 27001 standard. If it applies, we’ll tell you about it, and our compliance team and virtual CISOs will add insights directly into your reports. This will help you prepare for audits and flag any non-conformities in your ecosystem before an auditor finds them.
If there are other frameworks you’d like to see mapped to Field Effect MDR analytics, please get in touch—we’re constantly expanding this functionality because we know it will be key for customers moving forward.
Another big area is spotting gaps and non-conformities. One of the scariest parts of compliance is the fear that an auditor will discover something you didn’t know about. With Field Effect MDR, we identify issues well in advance so you can fix them.
Whether it’s an end-of-life operating system, weak encryption, or deprecated protocols detected on your network, we’ll alert you early so you can address them confidently before your audit.
Let’s also talk about the importance of the right team behind the technology. They should have deep compliance knowledge but also technical expertise—so they can translate requirements into actionable steps. They need excellent communication skills to explain clearly how to achieve compliance, and above all, humility. Compliance is about continuous improvement. Nobody knows every framework inside out; we’re all learning as we go. The best teams embrace that mindset.
At Field Effect, that’s exactly what we aim to provide—not just great managed detection and response with Field Effect MDR, but also support for your compliance journey. We want to be there with advice, policy writing assistance, and audit preparation. We can even help connect you with external auditors who understand Covalence and how it supports compliance requirements.
One more thing—if you head to our website, we’ve added a new compliance section. There, you can download mapping documents that show how Field Effect MDR meets requirements for standards like HIPAA, ISO 27001, and PCI DSS.
Q: Some companies are saying the Department of Defense is already requiring CMMC for indirect suppliers, and that contracts are being lost because deals for next year need to be closed now. Is that true? Are you hearing similar things?
A: My understanding is that final rulemaking for CMMC won’t be completed until sometime next year, and it wouldn’t be written into contracts until 2025. I’d be surprised if people are already losing business because, as of now, the third-party assessment organizations—the auditing firms—aren’t broadly performing CMMC audits unless you’re in a special program. So I’m not surprised to hear the uncertainty; we’re all kind of in “hurry up and wait” mode with CMMC, though I know it’s a concern.
Q: For PCI, if you accept, store, process, or transmit credit card information, should you adhere to some level of compliance?
A: Absolutely. That’s essentially what PCI DSS says: if you handle payment information—especially if you store it—you should comply. Even if you think PCI DSS might not strictly apply, if you’re handling that kind of data you want to minimize legal liability and be able to point to an implemented framework, even a voluntary one.
Q: Do we map to CMMC and NIST 800-171?
A: Yes. One of the mappings we completed was for NIST 800-171, specifically to support customers who need CMMC Level 2. There’s a Revision 3 of 800-171 likely releasing early next year, which could have implications for CMMC. As soon as it drops, we’ll publish an updated mapping.