Of the 3 domains of GRC, Governance is fairly simple to understand. It is significant for “rubber meeting the road” in terms of its usage in cybersecurity, and essentially boils down to 3 components itself:

Again, this notion of Governance is straightforward and fairly self-explanatory. For a well-managed and executed Cybersecurity program, Policies and Procedures must be developed. This documentation serves as a means of providing valuable information both internally to team members, and externally to any customers as assurance of good security practices.

Policies and Procedures vary in complexity and can encompass a few dozen specific documents for important business operations, but also a more monolithic form as a single document covering all necessary topics. There's functional benefits to each method, so it's pretty much dealer's choice on which way to go.

That said, more effective documentation in this realm contains specific references to the systems being used for the procedures, and references to the regulatory/framework standards serving as the basis for an organization's decisions. Policies and procedures can also vary in terms of elements to be considered — a smaller organization may not have a robust sense of documenting Secure Software Development Lifecycle procedures at all for example. It will all generally be scoped by

Here is a document developed by NIST to serve as a solid guideline for developing Policy documents.

Policies and procedures can also vary in terms of elements to be considered — a smaller organization may not have mature documentation of its Secure Software Development Lifecycle procedures for example. It will all generally be scoped by the Security Team that is managing the organizational posture. A perfect segue into:

Policies and procedures may lay down the law, but security leads and management are the sheriff and deputies.

A significant aspect of Governance is determining the appropriate team members (or contractors!) for providing the human touch in maintaining standards. Having policies in place mean very little if there’s nobody actually holding a team accountable for adherence.

Generally speaking, dedicating a select few people to manage the security posture of an organization is all that is required. Typical roles include:

More specific tasks and roles can be broken out among an organization, but these roles generally suffice to cover the bulk of needs for an organization. Often tasks such as Incident Response gets delegated to/from these roles, so there is a more practical level effort instead of simply passing on dictates from on high.

Further, there is an important relationship between these management roles and policy development. The security team should be regularly performing maintenance of the policies and procedures as organizational structures are frequently changing — not much use in having security policies apply to a product that is no longer being developed. Which leads into…

Determining the security initiatives to undertake is obviously an important part of the Governance side of the house. Much like how leadership of an organization must provide roadmaps for business growth, the growth and refinement of the security posture as well as execution of certain elements must be considered (e.g., developing plans to test business continuity procedures and orchestrating penetration testing). This planning is an important element in and of itself as organizational changes frequently warrant consideration for ongoing security standards.

Planning will also involve some level of Risk management, but that will be covered in the Risk section.

Governance is an almost self-explanatory measure. It is the steering element of an organization's cybersecurity program which develops and executes on the policies that dictate the security posture. As with any element of business, an organization's security team will have nuances and overlaps of duties, but that gets into nitty-gritty of things.

What, were you expecting some OTHER board game?

Quite a loaded question that seems obvious while at the same time being quite the rabbit hole. For a proper definition, I will defer to NIST:

“An effect of uncertainty on or within information and technology. Cybersecurity risks relate to the loss of confidentiality, integrity, or availability of information, data, or information (or control) systems and reflect the potential adverse impacts…”

From a practical standpoint, Risk can be considered as the analysis of threats an organization faces weighed against any vulnerabilities the organization has.

Clear as mud? Good! Now you know why there’s money in this type of work. Read on!

Chances are if you’re reading this page or are involved in cybersecurity from even a studious standpoint, you know what a vulnerability is. But for a good little refresher, a vulnerability is a weakness in an organization that exposes it to potential damage. In the same vein, a threat is whatever exploits the vulnerability to make that potential damage a reality.

Being cybersecurity fans, we tend to think of hackers and corporate espionage when we think of threat. We think of malicious actors inside and outside an organization seeking to steal data or bring the organization down by finding poorly written code that makes exposes everything.

But there are certainly less theatrical (and sometimes more theatrical) versions of vulnerabilities and threats. While we often think of malicious actors as exploiting employees that are not privy to reporting phishing emails, sometimes we overlook other significant vulnerabilities such as something as simple as a lack of a fire extinguisher close to a server room! The vulnerability (servers not doing well in fire) is still there, and the threat (a building fire) still exists, so we still have a Risk to consider!

Risks take all shapes and sizes — the fire-threatened server room is an example of a non-technical risk. As such, it is prudent for organizations to take stock of the potential Risks facing them and decide on what to do. Some examples to consider include:

This list is of course not exhaustive of all types of examples, but it demonstrates that Cybersecurity Risks can be well beyond the more obvious scopes.

For properly evaluating risk, an organization must consider the 2 primary factors mentioned earlier — the vulnerability and the threat. Each of these will have differing magnitude based on an organization’s scoping.

A common method among the pentesting side of cybersecurity tends to rank risks based on a matrix of Magnitude of Impact (MoI) vs Ease of Exploitation (EoE).

This is a conceptual model of how one can define risk, but it can grow exponentially or take on other metrics depending on who is looking at what aspect. If we were to apply a similar model to more of an Internal Risk (such as a disgruntled employee), then both their Magnitude of Impact and Ease of Exploitation would be directly correlated with any access privileges that employee has. And this same Risk extends to anybody in the organization, but while a system admin might be considered a High Risk, a building custodian could be considered Low Risk depending on the scope.

In some cases, what also appears to be a Risk may not actually be so. If you have a database that contains very important customer data like their birth dates, SSNs, and payment card info, exposure from that database would be massively risky. But if the database is behind a private intranet and accessible to only 2 people under an NDA and strict activity monitoring, then the Risk level of having the database itself can be considerably lowered.

The key point here is that when one considers the metrics of the vulnerability vs. threat. There are also multiple ways to calculate the risk factors facing an organization (link), the above model is a simple one that is easy to digest. But the idea is an organization can classify what actions to take in response to the risk

Which leads us to…

The crux of the Risk domain. With an understanding of Risk and how to evaluate its impact to an organization, those in charge of managing the Risks can make important decisions regarding it. Essentially there are 3 decisions when it comes to managing risk.

There are a few more actions an organizations can decide on, but these 3 are mainly what it boils down to. And they’re fairly straight-forward in theory.

The management in this regard usually boils down to the severity of the Risk itself, specific actions are usually based around factors such as cost of remediation, manpower/technical expertise required, practicality of the vulnerability itself, and considerations around business operations.

Risk management tends to warrant its own levels of policy within organizational Governance, and is a significant motivating factor for Governance practices. Risks also play into Compliance considerations as well since Compliance seeks to provide regulatory oversight into how organizations should best manage the Risks that face them.

In essence, Risk ties the 3 domains together into what actually must be done to protect organizations.

Compliance is arguably the towering entity of the GRC triad. There are the rules and what entity/entities oversee their adherence. And in the tightest of all nut shells, being compliant means you play by the rules — literally answering the question “Do you and your organization COMPLY with xyz rules?” After all:

With that in mind, however, not all rules get to apply. In some cases, regulations are required, in others, they can be “addressed” and some regulations are entirely voluntary and/or serve as guidance.

Note: * indicates a voluntary standard and compliance is based on internal decision-making (aka Governance) or legal obligations such as customer contracts

Different standards are used for different purposes. Some standards are mandatory by industry or business activities (i.e., PCI DSS for any organization that processes customer credit card data), while some are regarded on more of a voluntary basis (e.g., SOC2). What will justify the adherence to compliance standards will be based on multiple factors, such as:

This list has common factors in determining the pursuit of compliance but is not exhaustive. These considerations will ultimately contribute to the overall cybersecurity posture of an organization and the Governance and Risk discussions as well.

Even though most standards will be based on industry best practices, the prescriptive nature and strictness will vary greatly between standards. For example, HIPAA has several criteria that are considered “Addressable” in that an organization can have some level of compensating controls that offset a more prescriptive need (e.g., hosting confidential data on servers physically hosted by Microsoft Azure rather than a server found in the closet of an employee’s home) or can have exceptions made to not meet a specific criterion.

The notion of strictness help define a standard and can thus be more amenable to certain organizations based on scope. If an organization is just getting it’s feet wet in the cybersecurity space and does not have a high level of revenue, it probably does not need to call for a SOC2 attestation (this goes back to the Justification section above).

Further, the notion of strictness also applies to penalties in the event of non-compliance. If an organization is not compliant with ISO 27k, there is no direct penalty facing it beyond client relations as ISO is not a regulatory body. However, if that same organization violates GDPR standards, then it can face significant damages in terms of fines to the European Union.

Just like you should call in a house inspector before buying a home, so too does an organization need to have a set of eyes watching compliance. However, compliance can be determined internally by an organization depending on the standards. An organization can assign a Compliance Manager type role to an individual or group of employees, can they can provide oversight of NIST CSF compliance for example.

However, not all compliance standards can be audited internally and some should not. A SOC2 audit is performed by a third-party entity granted such power by AICPA (the body governing SOC2 standards). Beyond that, an internal audit may be subject to unintended bias that overlooks critical elements of standards.

In some cases, non-compliance may not even be readily discussed until AFTER a significant instance of non-compliance appears. The US Department of Health and Human Services does not conduct regular audits of organizations for HIPAA, but it will audit an organization in the event of a breach. In such a case, it would be a potentially cheaper option to engage a third-party to perform an audit as part of a “Gap Assessment” rather than shelling out money for fines. (The Office of Civil Rights has collected over $130 million worth of fines in the past 19 years!)

Working in tech, you can safely bet there are software tools around to determine compliance posture. With as much information that goes into determining compliance, it’s often more than one person can hold in mind effectively at any given moment. Tooling can be as simple as a spreadsheet to as complex as a whole automatic testing solution utilizing APIs for various systems.

Spreadsheets have the convenience of being available basically for free, but the cost lies in a) effective development of the sheet’s contents, and b) proper analysis of the content. It can be quite time consuming to develop and alter a functional system this way, especially if you are performing assessments for multiple clients.

Increasing complexity of compliance standards have yielded the creation of automated tooling for compliance. Tools such as Drata, myVCM, and Microsoft Compliance Center have begun stepping into make the auditing process easier. However, while the automation helps to generate good evidentiary material, we are still relatively in the infancy stage. Automated ratings tend not to pick up on nuances of scoping and can also generate false positives or negatives based on its analysis. Further, these tools may also not fully integrate with organizations’ systems and must be used judiciously.

I came into this field relatively light on technical skills compared to my colleagues. Although I am Security+ certified, I lacked robust experience in both the Red Teaming and Blue Teaming fronts. But getting involved with GRC has allowed me to grow my knowledge significantly in just a short time — not only in nuances of IT set ups, but also in the realm of penetration testing as I review, and sometimes contribute to, pentesting reports.

There is also variances in my day-to-day activities. Between Gap Assessment work and vCISO service work, one day I can go from contributing to tracking risks for a client to performing Security Incident Response, to analyzing policy documents, and even developing tools to make my jobs easier.

The variability in duties is actually enjoyable to me as it allows for more creativity and can prevent a sense of mundanity that might face more straightforward roles. I also have a strong sense of customer service, so this provides a means of getting that career desire met.

This list is by no means comprehensive, but can be helpful in determining who might be better served for GRC work.