In this post, I'll explain how I performed one of these assessments myself. I used an Azure cloud environment. I won't go over the process of how I created an account or set up a subscription. These are self-explanatory. However, I will show what steps I took and what standards I followed to complete an example of a typical regulatory assessment.

First and foremost, I created a resource group named GRC-Lab. I maintained default settings and chose the nearest region available to me. After creating the resource group, I launched a virtual machine called GRC-WIN-VM01. The VM was placed in the GRC-Lab resource group in the same region. We'll use Windows Server 2022 Datacenter as the image. Ordinarily, we'd want to optimize costs and use only what you need for an image with sufficient CPU. However, I compromised and used a larger size with an Azure spot VM. The size I wanted wasn't available, and Microsoft couldn't increase my quota due to the demand on their resources.

Notice how I left port 3389 (RDP) open to the public. This is intentional.

The first real step in a GRC analysis is identifying what assets there are and taking inventory of them. The second and third steps are identifying threats and vulnerabilities, respectively. We establish these variables by asking these three questions:

• What do we care about?
• What could harm it?
• Why could that harm succeed?

First, we look at the operating system.

Then the network.

Privileged accounts with access to the system.

Here's a table of identified assets from these steps:

If it holds value, grants access, or provides privilege, it’s an asset. Assets are not just servers; they include accounts, access, and permissions.

Next, identify threats. To do this, we ask three questions:

• Who would attack this?
• How would they access it?
• What attacks are common in the wild?

Keep in mind that threats can be internal or external. GRC addresses both. SOCs encounter threats like the ones above daily.

Finally, discover what vulnerabilities there are. These are weak points open to exploitation. Let's take a look at our network settings first.

The inbound port rules show what ports are open to the public, or if there are any. Open ports increase the attack surface.

Note: Within our VM configuration, port 3389 is open. This leaves the VM open to the internet. Brute-force and credential-based attacks are common on RDP 3389.

Where else should we look? Let's see which users are active and who has administrative access.

It shows that there is only one user (azureadmin) that has administrative access.

As for monitoring in Azure, the default mode does not indicate that any monitoring is taking place.

If we check the system logs, we can see every event within the OS is logged with an event ID, task category, and date/time.

If we make a table for the vulnerabilities we found, it might look something like this:

As you can see, I have not gone above and beyond in any way to protect my assets. Windows Defender and Windows Firewall are turned on with their default settings. This level of vulnerability is what you can expect with default settings.

With all this information collected, we can create a risk assessment report which includes an executive summary; scope and environment; asset, threat, and vulnerability summary; risk prioritization; security controls and compliance mapping; recommended mitigation actions; and overall risk posture. Here is what a professional risk assessment report looks like:

Risk Assessment Report

1. Executive Summary

This report summarizes the findings of a cloud security risk assessment conducted on a single Azure-hosted virtual machine, from a Governance, Risk, and Compliance (GRC) perspective.

The goal of this assessment is to identify critical assets, evaluate potential threat scenarios, assess vulnerabilities, quantify risks, and recommend security controls that align with recognized industry frameworks.

The assessment identified several medium-to-high risks, primarily related to exposed remote access, the absence of multi-factor authentication (MFA), inadequate operating system hardening, and limited centralized monitoring. Although no active exploitation was detected, these findings highlight common cloud misconfigurations that could be exploited if not addressed.

2. Scope and Environment

Assessment Scope:

● Single Azure Virtual Machine

● No additional cloud services or applications included

● Assessment performed from a GRC (non-exploitative) perspective

3. Asset, Threat, and Vulnerability Summary

4. Risk Prioritization

Risks were scored using a standard Likelihood × Impact model.

Risk Scoring Model:

● Likelihood: 1 (Low) → 5 (High)

● Impact: 1 (Low) → 5 (High)

● Risk Score = Likelihood × Impact

Risk Register (Core GRC Artifact)

5. Security Controls & Compliance Mapping

Control Mapping Table

Explanation:

● RDP attacks are mitigated by restricting inbound access to trusted IP addresses, a preventive control aligned with CIS Control 4, which focuses on secure configuration and controlled network access.

● Credential theft is addressed through multi-factor authentication (MFA), a preventive control mapped to NIST PR.AC, which emphasizes strong identity and access management.

● Operating system exploits are reduced through patch management, a corrective control aligned with CIS Control 7, ensuring vulnerabilities are remediated on time.

● Lack of visibility or detection is mitigated by enabling centralized logging, a detective control mapped to NIST DE.CM, which focuses on continuous monitoring and event detection.

● Privilege misuse is controlled through role-based access control (RBAC), a preventive control aligned with CIS Control 5, enforcing least privilege principles.

6. Recommended Mitigation Actions

● Restrict RDP access via Network Security Groups (NSGs) to trusted IP ranges.

● Enable multi-factor authentication (MFA) for all administrative accounts.

● Apply regular operating system patches and updates.

● Enable Azure Monitor or Defender for centralized logging and alerts.

● Implement role-based access control (RBAC) for Azure resources.

7. Overall Risk Posture

Based on the findings, the overall risk posture of the assessed environment is Medium to High. While the environment is small, the presence of exposed access paths and limited monitoring significantly increases risk.

Key Takeaways

Some things we learned along the way to produce a GRC risk assessment include:

● How to set up a cloud-based environment in Azure by creating a resource group and deploying a Windows VM to serve as the assessment scope.

● How to identify and document which critical assets, threats, and vulnerabilities with a cloud-hosted VM should be in the report.

● How to quantify cybersecurity risks.

● What mapping technical security controls to recognized industry frameworks looks like.

● What a professional GRC-style risk assessment report should look like.

● How to translate technical findings into business risk, supporting audit readiness, risk communication, and informed security decision-making.

It wasn't too long ago that I decided I wanted to pursue a career in the IT industry, transitioning from my chaotic hospital security job to something aligned with my degree--a B.S. in mathematics with a focus in computational science, to be exact. My problem was how. I had entertained the idea of becoming an actuary post-graduation; however, this never really suited my values. With the abysmal job market of 2023 (I graduated in December of 2022), it was clear to me things were going to be challenging. Amid the hiring freezes, followed by the mass layoffs due to the A.I. bubble, a new skill set was needed amongst those who would stand out to hiring managers. Obtaining a computer science degree was no longer the gold standard; in fact, many post-graduates claim a degree in computer science isn't worth it anymore, partly due to A.I.'s ability to code for entry-level roles. If one isn't able to compete for entry-level roles, how is one to hope they can even become a mid-level engineer, let alone enter the industry?

Luckily, I knew someone who knew someone who knew another someone. This individual worked at Accenture. They were quite forthright about how stagnant the industry was at the time of our chat. Though they mentioned that if I wanted to break into the industry, a bachelor's degree would not mean much compared to the pandemic hiring of 2020-2022, when you could show up after a simple programming bootcamp and get hired. She said the industry had shifted, and cloud skills were paramount. Gone were the old days of normal on-premises computing, and in were the cloud native solutions. Okay, get the AWS Certified Cloud Practitioner certificate, and I've got a chance, right? Well, not quite…

It seemed to me I'd be climbing up a steep mountain. While my mathematics/computational science degree gave me a strong theoretical foundation, I lacked a production-ready portfolio to prove I had skin in the game. So, where to go from here? Upon digging deeper into what companies desire from some prominent tech industry voices on YouTube, I found that many expect future employees to have a decent handle on cloud-native skills. How does one prove that? In comes the AWS Cloud Resume Challenge. One look at the project, and I thought, "This won't be too bad, I think..." Mind you, I decided to learn a programming language before diving headlong into this project, namely Python. This was considered the most widely used/desired language in the industry, and since I had taken Intro to Python Programming in college (and was a teacher's assistant for said course), it made the most sense to get a grip on this first, seeing that the challenge required some Python skills.

Fast forward, here I am working on the challenge. While the steps outlined are relatively straightforward, some were more taxing than initially anticipated. While most people who take this challenge loathe CORS (Cross-Origin Resource Sharing), I found my frustration in other areas. One of them was getting my Lambda function to work properly. Some of this was simple syntax that output an error that wasn't truly relevant to my issue. Sometimes it was policy attached to my execution function. At one point, so fed up that I couldn't understand why my policy was misaligned with my function, I decided to delete my function, CloudFront Gateway, and my DynamoDB table, and completely start over. This brought me back to how it was interacting with intoxicated patients in the Behavioral Health unit. You could tell them something, lay it out clearly and concisely, lead them to reason, only to end up back at square one with them asking you, "Why?" for the thousandth time. Yes, programming and debugging take patience, just like de-escalating behavioral patients. There are lots of whys and hows wrapped up in the process. When all else fails, go back to the foundation rather than going in circles. It was during one of these grueling debugging sessions, trying to move data from my API to my database, that I realized AWS infrastructure operates much like the workflows of my old hospital workplace.

If you haven't checked out the AWS Cloud Resume Challenge for yourself, there are a plethora of blogs out there describing the ins and outs of the challenge. For the sake of simplicity, here is an overview of what the challenge entailed:

Essentially, the challenge was constructing and integrating the front-end and back-end of a "static" website, then automating its deployment using CI/CD (Continuous Integration/Continuous Deployment). Since most DevOps engineers use the CLI in their day-to-day jobs, I needed to learn how to deploy my website from both the AWS CLI and the AWS Console. Note: I used Terraform, Visual Studio Code, and AWS CLI in lieu of some elements shown in the diagram.

To make sense of how these elements talk to one another, it's helpful to look at it through the lens of my old career in healthcare operations.

The Front End: Patient Check-In

Let's think of the website visitor as a family member coming to visit a patient. They start at the outer security desk/door screener, which acts like Route 53 (DNS), ensuring the visitor has the right address and routing them to the correct unit. Next, they meet the floor's HUC (Health Unit Coordinator), who acts like CloudFront (CDN). The HUC verifies the visitor’s identity and relationship to the patient, ensures the environment is appropriate to enter at the time (ACM/SSL Certificate), and directs them down the right hallway so they aren't roaming around sensitive areas where confidential information protected by HIPAA is discussed. Finally, they arrive at the patient's room. The patient's room is our S3 Bucket—it holds the actual content the visitor came to see--the patient (the HTML/CSS frontend).

The Back End: The Visitor Log

Every time a visitor steps into that room, we would like to log it. This is where the backend infrastructure kicks in. The act of walking into the room triggers a sensor—an API call. This call hits the API Gateway, which acts like the paging system notifying the nurse by phone, translating the front-end event into a directive the medical staff can understand. The pager alerts the Lambda Function (the Nurse). The nurse doesn't sit in the room permanently; they appear when triggered by the page, execute a specific task, and exit the room. The nurse’s task is to walk over to the DynamoDB Table (the Patient Chart/Logbook) and increment the visitor count by one. In reality, do nurses have to log when a visitor comes? Well, no, only if it is clinically relevant. Such would be if the patient has disruptive visitors who pose a safety concern, maybe this visitor has POA over this patient and has pertinent medical knowledge of the patient, or perhaps the patient just doesn't want visitors. All of these are valid reasons for charting visits. Whether or not the visitor is allowed into the room depends on the policy side of things.

The Infrastructure: Hospital Policy & Guardrails

None of this movement happens without strict oversight. IAM Policies act as the hospital's internal security team. They explicitly dictate which individuals have permission to access which areas of the hospital. Meanwhile, the Terraform within our CI/CD pipeline functions much like Epic (the Electronic Health Record system). Epic acts as the digital master record for the patient. Just as Epic automatically processes a clinician's input, runs safety checks, and instantly updates a patient's chart—our pipeline triggers when we push code changes from the AWS CLI to our GitHub repository, using Terraform to read the new configurations and smoothly update our live infrastructure without manual intervention. To keep sensitive data safe, we use a .gitignore file, which works exactly like HIPAA protocols, redacting sensitive credentials and PII before anything is pushed to a public space.

While no analogy is perfect, mapping these cloud services to the high-stakes, structured world of a bustling hospital helped me frame what I was building. It proved to me that the problem-solving, patience, and systemic thinking required in healthcare are the same traits that make a great cloud engineer.

The good news is that as the industry shifts, so do our skill sets. Now that the dilemma of 2023 has passed and the industry is settling, it is clear that pivoting post-graduation is a time-honored tradition in tech. Many of the best engineers enter the field from vastly different backgrounds, and I feel right at home among people with varied life experiences. It is much like my time in hospital security: everyone brought a unique perspective to the table, and I have found that I do too.

Was the Cloud Resume Challenge worth it? Absolutely. If you are reading this amid the challenges of the current job market, do not give up. Nothing truly precious in life comes easily, and anything worth doing will be hard—you can count on that. The key is simply to trust your foundations, stay patient, and keep moving forward.

Link to Cloud Resume Challenge