Declaration of Independence
Hello friend! I wanted to get your thoughts on something. I decided to declare independence from false assumptions when implementing cybersecurity requirements, specifically the assumption that certain requirements must be implemented using technical solutions and security tools, and rather, that, before buying another tool, we can save some cash and implement the requirement another way, in a way that has been used and understood for years, through administrative security controls! Below is the beginning of my Declaration of Independence:
When in the Course of organizational events, particularly deciding how to implement security requirements for a Governance, Risk, and Compliance (GRC) program, it becomes necessary for people to dissolve their assumptions that have unnecessarily connected them with costly solutions. Cybersecurity programs are endowed with certain unalienable risks, that among these are Loose change management, Limited incident response readiness, Lateral movement, et al. Yet, to secure such systems and organizations, we hold these truths to be self-evident that expensive or cumbersome technologies are not always created equal, nor are they required to get the job done. Rather, practical use of the more accessible means may be a candidate for such implementations and, possibly, result in a more secure environment than were such lofty prospects to be acquired. We, hereby, do solemnly publish and declare that our cybersecurity programs are now absolved from all allegiance to any overreaching expectation for implementation and are determined to implement security controls in accordance with the prudence and context of the system and data being secured and in such a way that the implementations truly mitigate the security risks posed against the assets needing protection and that are maintainable by the custodians of such assets. And for the protection of them, we do pledge to implement such controls in good faith and with due regard to the obligations required of us.
Be honest, awesome right? Probably not July 4th material, but I’m thinking we’re close!
Whether you’re talking about ISO 27001, CMMC, SOC 2, or HIPAA, there are a multitude of ways that security controls can be implemented. That’s why most cybersecurity frameworks are vendor-agnostic and can be implemented by companies of all shapes and sizes. Though this may be obvious to many, I’ve found that many people we work with or see online in public forums like Reddit and LinkedIn act as if the frameworks are more rigid or explicit than they are. Whether you’re new to GRC or you’ve been in the trenches of Risk Management for years, it’s always good to go back to the basics and have a refresher on key Security Elements. In this blog, I want to advocate for the validity of administrative security controls over costly and cumbersome technical solutions for implementing requirements from cybersecurity frameworks. We’ll start by reviewing the foundational concept around security controls and then discuss how they can be appropriately (and practically) applied to an Information System in order to satisfy requirements. My hope is that, after reading this, you’ll walk away a bit more open-minded to the possibility that the expensive tool that you were pitched isn’t necessarily the end-all, be-all that you were told it was.
Take Me Home!
After you spend a good amount of time developing governance programs, it’s sometimes easy to forget the mission while thinking about all the nuances, challenges, and tasks you face. It’s helpful to remember that everything we do when implementing requirements from a regulation/framework is to support one major, overarching goal – Risk Management. At the end of the day, we manage the risk of some sort of negative impact to certain valuable resources. This is the first important caveat when thinking about which controls to implement because cybersecurity 101 teaches that no system or asset is risk free. If there is a system or asset, there will always be some sort of risk to the Confidentiality, Integrity, and Availability (CIA) of it, and the ONLY thing you can do is manage the overall risk.
Now, Stevee-boy, why spend time on this? Thanks for asking! The reason these principles are important is because a proper understanding of the basics of risk management provides a good foundation and perspective for everything else we do in GRC. If your organization has external regulations or internal risk-based priorities for the security of the system and its data, implementing a security framework or standard like ISO 27001 or NIST SP 800-171 is one of the most common ways to mitigate the risks associated with these valuable assets. One of the reasons that security frameworks are so helpful is that they are flexible, meaning they are often designed with no specific type of system or organization in mind and are intended to fit a multitude of scenarios and situations. To maintain flexibility, these standards or frameworks are typically technology and vendor-agnostic. In many cases, they do not mandate the use of a particular technology for fulfilling requirements, nor do they require that the technology be utilized at all. If a technological solution is chosen, frameworks typically refrain from specifying any particular product vendor or brand.
Within a security framework are the actual security objectives/controls for a company to adopt and implement. These are the things that a company does within their system to mitigate the risks that have been identified. Implementing these requirements or objectives can be done in a variety of ways since, as I mentioned before, the requirements themselves are often not prescriptive in terms of methodology. So, it’s often up to the organization to determine the most effective way of implementing the requirements from the framework. This is where it would be helpful to review the three major types of control implementations. When implementing measures to secure a system or its assets, there are three types of controls. First, there’s “Technical Controls,” which are either technology solutions tools, or configurations of technologies or tools, that mitigate risks associated with the system. Then there are “Physical Controls,” which are the ways that an organization provides physical means of protecting the system and its assets. Things like locked doors and barriers are Physical Controls. Finally, you have “Administrative Controls,” which are documented policies, processes, or procedures that leadership enforces to set requirements for the other types of controls (i.e., technical and physical) and to set the standard for human behavior related to the system in question. In plain terms, Administrative Controls are the rules, processes, and expectations that leadership sets, so security doesn’t depend entirely on tools and technology.
The Squirrel in the Trees
The reason I went back to the basics there for a second was to remind us that, though not always equally effective, there are often more than one way to implement requirements. The goal should be to implement risk-based control implementations, not necessarily status-quo implementations. This, in turn, means that you may often be able to implement requirements using existing tools or technologies, or even use a different type of control than anticipated altogether, saving you resources that could be utilized for other efforts. It’s not always a nice fit, and technology solutions, though often with a steep price tag, may certainly be worth it in terms of the currency of sanity and time, but alternative measures or compensating controls are not uncommon in a mature GRC program. So, let’s walk through just a few examples of legitimate alternative governance safeguards from some different common vendor-agnostic frameworks where this approach may be more efficient all around.
Exhibit A: Meeting CMMC Data-At-Rest Requirements Without Buying New Tools (CMMC)
In this scenario, we’re dealing with an organization that must protect the confidentiality of Controlled Unclassified Information (CUI) at rest (per the security control SC.L2-3.13.16 from CMMC / NIST SP 800-171). The most common way of doing this is generally through the utilization of cryptography, such as Volume Encryption or Full Disk Encryption technologies. However, what if the organization is currently using a File Server that doesn’t support the FIPS-validation requirements because the cryptographic modules they have haven’t been certified through the NIST Cryptographic Module Validation Program (CMVP), or their old certificate from NIST CMVP has expired? Does the organization have to go purchase an entirely new file server that supports the FIPS requirements? Not necessarily. Why? Again, I’m glad you asked. Because the requirement to protect the confidentiality of CUI at rest doesn’t HAVE to be accomplished through the use of cryptography explicitly. One allowable way that this requirement could be satisfied without utilizing the technical control of encryption would be the implementation of physical security controls, such as locked doors with restricted access controls or security cameras physically present inside the room, or locked cages where that particular server sits, even within the data center, to ensure even more limited access controls. Though we encourage the use of FIPS-validated encryption wherever possible, it’s not required when other alternative controls can accomplish the same mission. In a formal assessment or audit, as long as documented well, compensating controls or alternative measures often work and demonstrate you understand the intent of the requirement!
One more, just for fun.
Exhibit B: When Secure Information Transfer Exists Without Data Loss Prevention (ISO 27001)
An organization may be expected to safeguard sensitive information whenever it is shared externally or moved between parties, as outlined in ISO/IEC 27001:2022 Annex A control A.5.14 on information transfer. In many environments, the first solution that comes to mind is deploying technical protections such as Data Loss Prevention (DLP) platforms, automated email filtering, or inspection tools designed to detect and stop improper disclosures. But what happens if the organization lacks the budget for enterprise DLP, or operates in a context where implementing such technology is impractical? Compliance does not necessarily require purchasing a specific tool. Instead, the control’s intent can still be achieved through well-designed administrative measures. For example, the organization could enforce a formal information transfer policy, require staff training on approved sharing methods, establish management approval workflows before sending sensitive data outside the business, define secure transfer expectations through contractual terms with third parties, and maintain clear accountability through disciplinary procedures for violations. While technical monitoring solutions may be ideal, ISO 27001 allows organizations to meet the objective through strong governance and procedural controls that effectively reduce the risk of unauthorized information transfer.
Conclusion
With regulatory requirements increasing and organizations being more skeptical regarding the privacy and protection of their systems and data, it only makes sense that the need for awesome solutions and tools to support organizational security goals be at the top of leadership’s mind. And, in many situations, it makes total sense from all sides to acquire a technology that makes your job just a tad bit easier.
Nonetheless, I do hope that this article has helped you think more critically about the exchange and the overall goal. Risk can be mitigated in an array of ways, and we definitely don’t want organizations to feel like their hands are tied and are required to implement specific technologies (especially the really pricey ones) when, in many cases, there are a plethora of more affordable and reasonable approaches!
If you’re looking into implementing robust cybersecurity requirements and are struggling to think through your approach, we, at IntelliGRC, would love to chat! We have amazing members on our team, as well as some amazing partners in the MSP and MSSP space, who are eager to help you reach your goals and figure this stuff out!
Until next time, Happy Implementing!
Frequently Asked Questions
What are administrative security controls?
Administrative security controls are policies, procedures, training, and governance measures that reduce cybersecurity risk through organizational enforcement rather than technology.
Do cybersecurity frameworks require specific tools?
Generally, no. Frameworks like SOC 2, CMMC, HIPAA, and ISO 27001 focus on outcomes, not specific products.
What is a compensating control in GRC?
A compensating control is an alternative safeguard that achieves the same security objective when a primary technical control isn’t feasible.
When should organizations invest in technical security tools?
Tools are often worth it when administrative controls alone cannot adequately reduce risk or when automation and monitoring are necessary.
