In that moment, your heart rate spikes. We have been conditioned to see audits as a pass-or-fail exam—a binary world where you are either a compliant hero or a security villain. But management system auditing under ISO/IEC 17021-1 is more nuanced than that. It is not a grade; it is a professional mirror. If you want to survive the closing meeting without a panic attack, you need to understand the language they are speaking.

This edition of GRC Lab is brought to you by … Kertos (Advertisement)

Europes #1 Compliance Platform Kertos, automates your compliance standards, such as ISO 27001, GDPR, SOC 2, or the EU AI Act – from the initial analysis to the audit and as a sustainable solution far beyond.

Discover Kertos*

The Types of Audit Findings

In the context of a management system audit, a “finding” is not just a random observation. According to the standard, audit findings are used to summarize conformity and detail nonconformity. These are the data points used to determine if your system is actually doing what it says it is doing.

1. Conformity

This is the goal. Conformity is the fulfillment of a requirement. It means your processes match the criteria of the standard, they are effectively implemented, and they are capable of achieving your organization’s stated policy and objectives.

2. Nonconformity

This is the term that causes the most stress, but its definition is quite clinical. A nonconformity is simply the “non-fulfilment of a requirement.” It represents a gap between the “audit criteria” (the rules) and the “audit evidence” (the reality of what is happening). When an auditor records a nonconformity, they must identify the specific requirement that isn’t being met and provide the objective evidence—the facts—that prove the gap exists.

3. Opportunities for Improvement (OFI)

An OFI is a suggestion where a process is technically meeting the requirement but could be more effective or efficient.

There is an important “integrity” rule here for auditors: an audit finding that is a nonconformity shall not be recorded as an opportunity for improvement. This prevents auditors from “being nice” and hiding a systemic failure behind a friendly suggestion.

Grading the Gaps: Minor vs. Major

Not all nonconformities carry the same weight. The distinction isn’t arbitrary; it depends entirely on a single threshold: does the mistake threaten the “intended results” of your management system?

The Minor Nonconformity

A minor nonconformity is defined as a “nonconformity that does not affect the capability of the management system to achieve the intended results.”

Think of this as a slip-up. It is usually a single instance or a small, isolated mistake in a process that is otherwise healthy.

• Example 1: The Outdated Review. Your policy says you review your firewall rules every six months. The auditor sees that you did the last three reviews on time, but the most recent one was delayed by two weeks because the admin was on leave. The review happened, but it missed the deadline. This is a non-fulfillment of your rule, but the “intended result”—maintaining secure firewall rules—is still being met.

• Example 2: The One-Off Oversight. You have a fleet of 100 laptops. The auditor samples five and finds that one doesn’t have the “Property of [Company]” sticker required by your asset management policy. However, the laptop is fully encrypted, tracked in your MDM, and has a strong password. The security intent is met; the sticker is an isolated administrative oversight.

The Major Nonconformity

This is a much more serious situation. A major nonconformity is a “nonconformity that affects the capability of the management system to achieve the intended results.” If you have a Major finding, the auditor is essentially saying your system is broken in a fundamental way.

Under the standard, a finding is classified as “Major” in two primary circumstances:

1. Significant Doubt: This occurs when a gap is so large that the auditor can no longer trust your system.

   • Example: An auditor asks to see your Risk Assessment—the foundation of any ISO system. You show them a document from three years ago that hasn’t been updated to reflect your move to the cloud. Because the foundation is missing or irrelevant, there is “significant doubt” that your controls are actually protecting the right things.

2. Systemic Failure: This is when “a number of minor nonconformities associated with the same requirement or issue” are found.

   • Example: The auditor checks your offboarding process. They find one ex-employee still has email access. Then they find another. Then they find a third. Each one might be a “minor” slip-up on its own, but together they prove that your offboarding process is non-existent or ignored. The “intended result”—denying access to former staff—is not being achieved.

Essentially, a Major nonconformity means the auditor cannot recommend you for certification (or maintenance of it) until the root cause is addressed and the fix is verified.

What Do You Think? Two Real-World Scenarios

To help this sink in, let’s look at two real-world scenarios.

Scenario 1: The Vague Background Check

An organization has a clear policy for screening new employees. One requirement is that a criminal records check must be conducted for every candidate. During the audit, the auditor finds that the checks are being done, but there is no written process explaining what happens next. There are no criteria for what kind of record would disqualify someone. For instance, if a candidate has a minor record for speeding, it isn’t clear if they would still be hired. The HR team says they “just use their best judgment,” but nothing is documented.

Scenario 2: The MFA Gap

A company uses Microsoft 365 for everything—emails, sensitive spreadsheets, and internal documents. They use Microsoft Entra as their identity provider. Their internal security policy is very specific about password complexity, and the auditor confirms that these rules are strictly enforced. However, you notice that Multi-Factor Authentication (MFA) is not enabled. The organization argues that their passwords are “complex enough” and that the standard doesn’t explicitly name “MFA” as a mandatory requirement for their setup.

The Verdict

Here is how a professional auditor would likely view these cases:

Scenario 1: Nonconformity

This is a Nonconformity. While the organization is performing the check (doing the “work”), they have failed the requirement to have a process that produces “consistent, valid, and comparable results.” By relying on “best judgment” without documented criteria, the screening process is arbitrary. If two different HR managers look at the same criminal record, they might make two different decisions. This lack of a defined process is a clear non-fulfillment of management system requirements.

Scenario 2: Opportunity for Improvement (OFI)

This is an Opportunity for Improvement. While modern security best practices virtually demand MFA, most high-level standards are “technology neutral.” If the organization has identified their risks and decided that complex passwords meet their specific security objectives, the auditor cannot immediately issue a nonconformity just because they personally prefer MFA. However, the auditor would record this as an OFI, noting that the “intended result” of data protection would be significantly strengthened by adding a second layer of authentication.

What do you think about these verdicts? Would your team agree, or would the “best judgment” argument hold up in your office?

Make yourself irreplaceable, even to AI.

Most people think they can “YouTube” their way to ISO 27001 certification. They watch 100 videos, read 50 PDFs, and then hit a brick wall the second they try to establish the ISMS in their own company.

I decided to fix that.

I’ve transformed our ISO/IEC 27001 Lead Implementer Course into a community-first experience.

When you join, you’re not just buying another “member’s area” with a bunch of dusty videos. You’re getting me in your corner.

I’ve upgraded the entire program so that you have a real partner throughout the process. Stalled on a specific control? Need a second pair of eyes on your documentation before the Stage 1 audit begins? I’m right there with you.

Stop playing “compliance roulette” with your certification. Work with someone who has been across the finish line hundreds of times and knows exactly where the traps are hidden.

Enroll Today

GRC Lab

Be the GRC Practitioner AI can't replace.

By Aron Lange

*Affiliate Link: If you purchase a license through this link, we receive a commission at no additional cost to you.

The response is often a confident, “Yes, we are ISO 27001 certified.”

That answer is misleading.

This edition of GRC Lab is brought to you by … Kertos (Advertisement)

Europes #1 Compliance Platform Kertos, automates your compliance standards, such as ISO 27001, GDPR, SOC 2, or the EU AI Act – from the initial analysis to the audit and as a sustainable solution far beyond.

Discover Kertos*

An ISO 27001 certificate proves exactly one thing: you have a management system that meets the ISO standard. It does not prove you are compliant with the law. It certainly doesn’t prove you are immune to regulatory fines.

Here is why you need to stop treating a security certificate as proof of legal compliance.

1. The Auditor Is Not Checking the Law

To understand the certificate, you have to understand the rules the auditors follow. They don’t just make things up; they follow a strict standard called ISO/IEC 17021-1.

This document contains a specific note that ends the debate immediately:

When an auditor visits your company, they are auditing your management system, not the applicable legal, regulatory and contractual requirements. They shall only look for evidence that you meet requirements of the ISO/IEC 27001 standard. Not more, not less.

Furthermore, the standard for bodies providing ISMS audits, ISO/IEC 27006-1, explicitly states that while auditors need to know the general legal landscape, this “does not imply a profound legal background.”

Auditors are not lawyers. They do not have the authority or the training to interpret complex regulations like NIS2. If an auditor tries to certify that you are legally compliant, they are breaking their own rules.

2. They Audit the “Approach,” Not the Outcome

So, what are they actually checking?

Under Control 5.31, the auditor verifies that you have identified legal requirements and documented your “approach to meet these requirements.”

The key word is “approach.”

The auditor checks if your procedure for identifying laws is sound. They verify that you have a list of laws and a plan to address them. They do not check if that plan would hold up in court.

If you have a procedure to review compliance, and you follow that procedure, you pass the audit. You can technically pass an ISO 27001 audit while being in breach of a specific regulation, simply because the auditor’s job is to verify you have a mechanism to manage the risk, not to confirm you have solved it.

Subscribe now

3. The Standard Allows You to “Opt-Out” of Laws

This is the most surprising reality for many business leaders. ISO/IEC 27001 gives you the option to choose which requirements you address.

Clause 4.2 requires you to identify interested parties (like regulators) and their requirements. But it then asks you to decide “which of these requirements will be addressed through the information security management system.”

This implies a choice. You identify the requirements, and you determine which ones fall within the scope of your system.

If you list a regulation like NIS2 in your Statement of Applicability (SoA), the auditor checks it for “relevance,” not conformity. The standards clarify that these references are not used for conformity assessment. You are showing you considered the law, not proving you obey it.

The Takeaway

An ISO 27001 certificate is a valuable asset. It builds trust and proves you have a rigorous framework for managing risk.

But it is not a legal shield. If a vendor claims their ISO badge makes them compliant with GDPR or CCPA, they are incorrect. The certificate verifies the system, not the legal result. Keep that distinction clear to maintain a realistic view of your security posture.

Make yourself irreplaceable, even to AI.

Watching videos is a great start, but implementing an entire ISMS requires a structured approach combined with advice from those who already did it.

If you are ready to master the standard and get certified, I invite you to enrol in my ISO/IEC 27001 Lead Implementer Course.

New Update: I have recently upgraded the program. You now have the unique opportunity to work directly with me inside the course. Whether you are stuck on risk methodology or need a second pair of eyes on your scope, I’m here to help you cross the finish line.

Enroll Today

GRC Lab

Be the GRC Practitioner AI can't replace.

By Aron Lange

*Affiliate Link: If you purchase a license through this link, we receive a commission at no additional cost to you.

This edition of GRC Lab is brought to you by … Kertos

Europes #1 Compliance Platform Kertos, automates your compliance standards, such as ISO 27001, GDPR, SOC 2, or the EU AI Act – from the initial analysis to the audit and as a sustainable solution far beyond.

Discover Kertos

In this session, we cover:

• The “Planning” vs. “Execution” Trap: Clarifying the difference between Clauses 6.1.2 and 8.2.

• The 3 Pillars of Assessment: A detailed look at Risk Identification, Risk Analysis, and Risk Evaluation.

• Risk Owners: Who they actually are (hint: it’s usually not the IT department).

• Methodologies Explained:

  • Qualitative Analysis: How to use a Risk Matrix (Likelihood vs. Impact).

  • Quantitative Analysis: How to calculate Single Loss Expectancy (SLE) and Annualized Loss Expectancy (ALE).

• Real-World Scenario: A practical example involving a Data Center in Hawaii and... a volcano. 🌋

Learn ISO 27001 Together with Me

Watching videos is a great start, but implementing an entire ISMS requires a structured approach combined with advice from those who already did it.

If you are ready to master the standard and get certified, I invite you to enroll in my ISO 27001 Lead Implementer Course.

New Update: I have recently upgraded the program. You now have the unique opportunity to work directly with me inside the course. Whether you are stuck on risk methodology or need a second pair of eyes on your scope, I’m here to help you cross the finish line.

Enroll Today

But there is a catch. This window is closing very soon.

Here is how to grab your copy before the rules change.

This edition of GRC Lab is brought to you by … Kertos

Europes #1 Compliance Platform Kertos, automates your compliance standards, such as ISO 27001, GDPR, SOC 2, or the EU AI Act – from the initial analysis to the audit and as a sustainable solution far beyond.

Discover Kertos

What is ISO 27000?

The ISO 27000 family of standards is a set of guidelines developed by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) under the joint ISO and IEC subcommittee, ISO/IEC JTC 1/SC 27. Its purpose? To offer organizations a robust and comprehensive framework for managing and improving their information security.

The ISO 27000 series is not just one standard but a suite of inter-related standards, each providing guidelines and requirements addressing various aspects of information security. Together, they form a cohesive model for implementing and managing a robust Information Security Management System (ISMS).

ISO 27000 is the “root” of this family. It doesn’t tell you what to do. Instead, it explains the terms and the big picture. It defines the vocabulary so everyone on your team speaks the same language.

The Four Categories

The family is split into four main groups:

• Terminology: Standards like ISO 27000 that define words and concepts.

• Requirements: These are “normative” standards. They are the only ones you can be audited against. ISO 27001 is the most famous example.

• General Guidelines: These explain how to meet the requirements. ISO 27002 is a great example of this.

• Sector-Specific Guidelines: These are for specific industries, like telecommunications or healthcare.

Why it is free (for now)

ISO typically offers terminology standards for free on their website. Since the current version of ISO 27000 is mostly about definitions, it costs zero dollars.

But a new version is coming in early 2026. This update will include more than just definitions. It will cover principles and relationships between standards. Because it has more content, ISO will likely start charging for it.

How to get it

1. Go to iso.org.

2. Search for ISO 27000.

3. Add the current version to your cart.

4. Check out for free and download the PDF.

Ready to stop learning in isolation?

You’ve just read about the theory, but implementing GRC in the real world is a different beast. For years, I only offered digital courses where you had to figure out the hard parts alone.

That changes now.

I have opened the doors to the GRC Lab. This is no longer just a library of on-demand videos; it is a direct line to me and a community of peers.

When you join, you get:

• Access to Me: Weekly live Q&A sessions to solve your specific roadblocks.

• Expert Workshops: Deep dives into topics AI can’t teach you.

• The Full Course: My complete ISO 27001 Lead Implementer training.

• And so much more!

Enroll today

Subscribe now

The German Federal Office for Information Security (BSI) recently released the Community Draft for the 2025 version of the Cloud Computing Compliance Criteria Catalogue—commonly known as C5.

For organizations relying on cloud services, C5 has become a primary benchmark for assessing vendor security. It pushes beyond simple checkboxes, requiring providers to prove that their security controls actually work.

With the 2025 draft, the BSI is updating the framework to address modern realities like Artificial Intelligence in control systems, sustainability reporting, and stricter data sovereignty requirements.

Here is a detailed look at what C5 is, how the framework functions, and what is changing in this latest version.

What is C5?

C5 stands for Cloud Computing Compliance Criteria Catalogue. It is a government-backed standard that defines a baseline level of information security for cloud service providers (CSPs).

Unlike a simple certification where a provider passes a test once and receives a badge, C5 acts as a reporting standard. It provides a structured catalog of criteria that an independent auditor uses to evaluate the provider. The output is not a certificate, but a detailed attestation report. This report gives customers transparency into the provider’s internal processes, allowing them to make informed risk assessments.

While developed in Germany, C5 is recognized internationally and is often used by hyperscalers (like AWS, Microsoft Azure, and Google Cloud) to demonstrate compliance across European markets.

How the Framework Works

The C5 framework operates on the principle of transparency. It dictates what must be audited, but it relies on international auditing standards for how it is done.

The Audit Standard: ISAE 3000

C5 audits are conducted according to the ISAE 3000 standard. This is a rigorous assurance standard used by accountants and auditors. It ensures that the audit is objective and evidence-based.

There are generally two types of reports a provider can issue:

• Type 1: Confirms that the provider’s security controls are designed correctly at a specific point in time.

• Type 2: Confirms that the controls were not only designed correctly but were also operating effectively over a specific period (typically 6 to 12 months). Most mature organizations require a Type 2 report.

Anatomy of the C5:2025 Criteria

The 2025 draft retains the core structure of previous versions but refines the content. The catalog is divided into specific domains and criteria types.

1. Basic vs. Additional Criteria

The criteria are split into two levels to accommodate different security needs:

• Basic Criteria: These are the mandatory minimums. To state compliance with C5, a cloud provider must meet all basic criteria. These cover standard industry best practices for secure cloud operations.

• Additional Criteria: These are context-specific measures. While technically optional for a general C5 report, they are often required for providers aiming to serve government entities or industries with high protection needs. A key focus here is “Technical Service Sovereignty”—ensuring the cloud service can operate independently of non-EU interference.

2. The Boundary Conditions (BCs)

Before getting into the technical controls, C5 requires providers to disclose “Boundary Conditions.” These describe the environment in which the cloud service operates.

The 2025 draft introduces critical updates here:

• BC-01 (Jurisdiction & Data Location): Providers must clearly state applicable law and jurisdiction. Crucially, they must now explicitly list locations for customer data, account data, and derived data (like logs and telemetry). This separation is vital for addressing sovereignty risks, such as foreign support teams accessing sensitive metadata.

• BC-06 (Sustainability & ESG): New in 2025. This promotes transparency regarding environmental impact. Providers are encouraged to disclose data on energy efficiency, water usage, and adherence to standards like ISO 14001 or the EU Corporate Sustainability Reporting Directive (CSRD).

• BC-07 (AI in Internal Controls): New in 2025. This does not just cover AI as a product sold to customers; it covers AI used by the provider to run their systems. If a provider uses AI models for internal control activities (e.g., anomaly detection in logs), they must disclose whether the model is proprietary or third-party, and how they ensure the model remains secure.

3. The Domains

The criteria themselves are grouped into roughly 17 thematic domains called areas. While the exact count of criteria can fluctuate slightly between drafts, they generally cover:

C5 vs. SOC 2: What Are the Differences?

While both frameworks are used to prove a cloud provider’s security, they differ significantly in origin, flexibility, and philosophy.

1. Origin and Market Focus

• SOC 2 (System and Organization Controls 2): Developed by the AICPA (American Institute of Certified Public Accountants). It is the de facto standard in the US market and is widely recognized globally for SaaS companies.

• C5: Developed by the BSI (German Federal Office for Information Security). It is essential for doing business in Germany (especially with the public sector) and is increasingly respected across the EU as a “higher bar” for transparency.

2. Principles vs. Criteria

• SOC 2 is Principles-based: It uses “Trust Services Criteria” (Security, Availability, Confidentiality, Processing Integrity, Privacy). Only “Security” is mandatory; the provider chooses which of the others to include. The provider also defines their own controls to meet these criteria. This offers flexibility but can lead to variability in report quality.

• C5 is Criteria-based: It is prescriptive. The BSI defines a specific catalog of “Basic Criteria” that must be met. A provider cannot simply “scope out” a difficult requirement if it is a Basic criterion. This ensures a consistent minimum baseline across all C5 reports.

3. Depth of Transparency
C5 places a heavier emphasis on “system description” transparency. The “Boundary Conditions” (like the new AI and jurisdiction disclosures) force providers to reveal structural details about their service—such as data locations and legal subjection—that might be glossed over in a standard SOC 2 report.

4. Combined Audits
Because both standards use the ISAE 3000 auditing framework, they are often audited simultaneously (”audit once, report twice”). A provider can map their internal controls to both the SOC 2 criteria and the C5 catalog, saving time and costs while satisfying both US and EU customers.

What Has Changed in the 2025 Draft?

The C5:2025 draft represents a significant structural and content modernization, largely driven by alignment with the European Union Cybersecurity Certification Scheme (EUCS).

1. Integration of Modern Standards and Feedback

The BSI didn’t work in isolation. The draft incorporates:

• Updated Standards: Alignment with CSA Cloud Controls Matrix v4, ISO/IEC 27001:2022, and the NIS2 Directive.

• Community Input: Feedback from cloud providers, auditors, and consultants was directly used to refine existing criteria and address practical hurdles found in C5:2020.

2. New Technical Focus Areas

The catalog has been expanded to address specific modern technologies and challenges:

• Emerging Tech: New criteria cover Container Management, Post-Quantum Cryptography, and Confidential Computing.

• Supply Chain Security: Enhanced focus on supply chain management risks.

• Sovereignty & Separation: Deeper examination of tenant separation and the technical implementation of data sovereignty.

• Data Applicability: Sharpened definitions on how individual criteria apply to different data types.

3. Structural Overhaul for Clarity

The structure has been revamped to make auditing easier and more transparent, mirroring the EUCS approach:

• Sub-Criteria: Criteria are now broken down into distinct sub-criteria. This makes it easier to map controls to internal systems and simplifies the audit process.

• Sharpen vs. Complement: “Additional Criteria” are now explicitly classified to avoid ambiguity:

  • Additional Sharpen: Stricter requirements that elevate an existing basic criterion.

  • Additional Complement: Entirely new requirements that supplement the basics.

4. Machine-Readable Formats

While the Community Draft is available in English (PDF and XLSX), the final version will mark a technological shift. It will be published in German and English across PDF, XLSX, and YAML formats. This move to machine-readable formats paves the way for automated auditing and continuous compliance monitoring, replacing manual spreadsheets with code.

Conclusion

C5:2025 represents the evolution of cloud security from purely technical “firewalls and passwords” to a broader view of risk. It acknowledges that legal jurisdiction, AI reliance, and environmental impact are now part of the security conversation.

For cloud customers, this draft indicates that future attestation reports will provide more data points for vendor risk assessment. For cloud providers, it is a signal to prepare for deeper scrutiny regarding their data supply chains and automated control systems.

Cut Implementation Time in Half

You know that achieving ISO 27001 certification is a critical milestone for your organization and a major step for your career. But right now, the path forward feels less like a clear roadmap and more like a frustrating maze?

Then our ISO/IEC 27001 Lead Implementer Course is exactly what you need!

Enroll Now

Subscribe now

I remember sitting in security meetings at the very start of my career, feeling completely lost. Words like ‘threat’, ‘vulnerability’, and ‘risk’ were tossed around interchangeably, and it felt like a game where the rules kept changing. I was confused, and honestly, sometimes irritated because what one expert explained to me often contradicted what the next one said.

It didn’t happen overnight. It took years of working in GRC and reading countless resources for the fog to lift. Slowly, but surely, I started to see the underlying structure. I realized that risks and controls weren’t just random components, but gears in a machine. I began to map out the relationships: how a threat needs a vulnerability to cause harm, and how that harm only matters if it touches the assets an organization actually cares about. Once I understood these connections, the noise faded.

To understand how this machine works, we first need to look at the process that drives it: the Risk-Based Approach.

The Foundation: Risk Management

Information security management is about protecting organizations from potential events that can cause harm to their business. This is the risk-based approach.

Risk management is typically aligned with the following steps.

Establish Context

Before diving into risk identification or analysis, it’s crucial to establish the context in which the organization operates. This involves understanding the internal and external factors that can affect the organization’s assets. Establishing context provides a lens through which risks can be identified and evaluated.

Risk Identification

This stage involves identifying what could go wrong, how, and why. Similar to spotting the key players and strategies of an opposing team, risk identification is about recognizing the threat sources, threat events, vulnerabilities, and assets at risk. This provides a comprehensive list of risks that need to be further analyzed.

Risk Analysis

Once the risks are identified, they need to be analyzed to understand their nature, likelihood, and impact. Risk analysis provides a detailed view of each risk, helping the organization to prioritize them. This will help organisations to understand which scenarios are most likely to happen and how damaging they can be if not properly treated.

Risk Evaluation

Risk evaluation involves comparing the analyzed risks against pre-defined criteria to decide which risks need to be treated. This can be thought of as deciding which opponent’s plays need the most defensive focus. The evaluation helps in allocating resources more effectively by focusing on the most critical risks.

Risk Treatment

This stage involves selecting one or more options for modifying the risks and implementing those options. Risk treatment can involve risk avoidance, risk modification, risk sharing, or risk retention. Please note that the impact of risks can not be mitigated to zero. There will always be a residual risk, unless it can be completely avoided.

Risk Monitoring

Last but not least, risks need to be continuously monitored and reviewed to assess the effectiveness of the risk management process and to identify any changes in the risk landscape. I like to state that risks never retire. For the moment a risk might be properly taken care of, but as soon as a control fails, threats evolve, or new vulnerabilities arise, this risk must return to our attention.

Threat Sources: The Starting Point

According to the National Institute of Standards and Technology (NIST), Threat Sources are defined as the origin of adverse events that could potentially harm an organization’s assets and operations. These sources can be intentional or unintentional and can come from a variety of places such as nature, individuals, or organizations.

NIST categorizes Threat Sources into two main types:

1. Adversarial: These are intentional actions taken by individuals, groups, or organizations with the motive of causing harm or exploiting vulnerabilities. Adversarial threats include hackers, terrorists, insider threats, and even competitors.

2. Non-Adversarial: These are unintentional actions or natural events that could potentially harm an organization but lack a targeted intent. Examples include natural disasters like floods or earthquakes, accidental data deletion by an employee, or system failures due to a bug.

By understanding the nature and types of Threat Sources as defined by NIST, organizations can better prepare for, and mitigate, various risks that may affect them.

From Threat Sources to Threat Events

Threat Sources impose Threat Events, which are specific actions or incidents that can potentially harm your organization. For example, a hacker (Threat Source) might attempt to break into your network (Threat Event).

Vulnerabilities: The Weak Spots

Vulnerabilities are the weak spots in your system where Threat Events can sneak in. These could be outdated software, weak passwords, or even a staff member who’s not trained in security protocols.

Supporting Assets

Vulnerabilities often expose Supporting Assets, which are the various components of your system that aren’t core to your business but are still important. These can include:

• Hardware: Servers, computers

• Software: Applications, databases

• Network: Internet connection, firewalls

• Personnel: Employees, contractors

• Sites: Physical locations like offices or data centers

Primary Assets

Primary Assets are what your business absolutely needs to function. These can be your main business processes or crucial pieces of information. Supporting Assets enable these Primary Assets to function. For example, your network (Supporting Asset) enables your online sales platform (Primary Asset).

The Chain Reaction: Security Events and Incidents

When a Threat Event exploits a vulnerability, it causes a Security Event. Not all Security Events are disastrous; some might be easily contained or harmless. However, when a Security Event has a significant negative impact, it is classified as a Security Incident. These incidents can compromise your operations and, ultimately, your Primary Assets.

Implementing Controls Through Risk Treatment

Once you’ve identified your Threat Sources, analyzed your vulnerabilities, and assessed your risks, the next step is to implement controls to manage these risks effectively. In the realm of information security, controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets.

Types of Controls Based on Risk Treatment

Controls are generally determined during the Risk Treatment phase and can be categorized into three main types:

1. Preventive Controls: These are measures designed to prevent an unwanted or unauthorized activity from occurring. They act as the first line of defense in risk mitigation. For instance, strong user authentication can prevent unauthorized access.

2. Detective Controls: These controls are aimed at detecting and alerting when an unauthorized or unwanted activity occurs. They don’t prevent an action but can trigger an alert or initiate corrective measures. An example would be intrusion detection systems that notify administrators about suspicious activities.

3. Corrective Controls: These come into play after a threat event has occurred, aiming to minimize the impact and bring the system back to its secure state. Data backups and system recovery plans are examples of corrective controls.

Make yourself irreplaceable, even to AI.

Understanding the theory is one thing; building a system that works in the real world is another.

If you want to move beyond the basics and learn how to construct an Information Security Management System from the ground up, my ISO/IEC 27001 Lead Implementer course is the perfect next step. We go deep into the practical application of these concepts, turning the “what” into the “how.”

November Sale:
I am currently running a special sale for the month of November. This is the perfect time to invest in your career and build skills that make you irreplaceable, even to AI. Don’t miss the chance to grab the course at a discounted rate before the month ends.

Buy Now

Subscribe now

When you look at the ISO/IEC 27001 controls for personnel security, it’s easy to just go down the list. You start at the top and work your way to the bottom. Most auditors do exactly that.

It gets the job done, but it misses the bigger picture.

Here are the standard personnel security controls (A.6.1 – A.6.8) that you usually face:

• A.6.1 Screening

• A.6.2 Terms and conditions of employment

• A.6.3 Information security awareness, education and training

• A.6.4 Disciplinary process

• A.6.5 Responsibilities after termination or change of employment

• A.6.6 Confidentiality or non-disclosure agreements

• A.6.7 Remote working

• A.6.8 Information security event reporting

Auditing these in numerical order is fine, but it feels disjointed. Real life doesn’t happen in numerical order. A better approach is to audit the employee lifecycle.

By grouping these controls into “Before,” “During,” and “After,” you follow the actual path of a staff member. It also makes sense to pull in a few controls from outside the A.6 category. HR and IT have to talk to each other for security to work, so your audit should check those connection points too.

Here is how you could structure such an audit.

Phase 1: Before Employment (The Onboarding)

This is where you check how a person gets into the company. You are looking for the handoff between HR signing the paperwork and IT flipping the switch on access.

Start with the HR basics. You need to verify A.6.1 Screening to ensure background checks happen before the person starts. Then check A.6.2 Terms and conditions and A.6.6 Confidentiality agreements. These are your legal safety nets.

But paperwork doesn’t give a user access to the network. This is where you should bring in the “A.5” controls to see if the process actually works.

Ask how IT finds out a new person is starting (A.5.16 Identity management). If HR sends an email or opens a ticket, is it timely? Once IT knows the person exists, how do they know what folders or software to unlock? That’s A.5.18 Access rights. You want to ensure the new hire doesn’t just get “admin access” because it’s convenient.

Finally, check the logistics. How does the user get their initial password securely (A.5.17 Authentication information)? If they are sent a laptop or phone, track how those assets are assigned to them.

If you audit these together, you can catch the gaps where HR thinks IT is handling it, and IT thinks HR is handling it.

Phase 2: During Employment (The Working Life)

Once the employee is settled, the risks change. Now it’s about behavior.

Check A.6.3 Information security awareness. Are they actually learning anything, or just clicking “Next” on a slide deck? Look for evidence of real training.

You also need to look at A.6.7 Remote working. Since hybrid work is normal now, check the policy for working from home. Ensure the security rules apply just as strictly at a kitchen table as they do in the office.

And if someone breaks those rules? Check A.6.4 Disciplinary process. You want to see that there is a formal process for handling security violations, not just a verbal warning.

Phase 3: After Employment (The Offboarding)

This is usually the riskiest phase. When someone leaves, the clock starts ticking.

Start with A.6.5 Responsibilities after termination. HR should remind the departing employee that their confidentiality obligations don’t end just because their paycheck did.

Then, immediately pivot to the technical controls. This is often where the process fails.

Check A.5.16 Identity management and A.5.18 Access rights. How fast was the account disabled? Did it happen the minute they walked out the door, or a week later?

Don’t forget A.5.11 Return of assets. Verify that laptops, keys, and badges were collected and logged.

A Note on A.6.8

You might notice I left out A.6.8 Information security event reporting.

While it is technically a “people” control, it fits much better in an audit of Incident Management. Save it for that session. It makes more sense to discuss how people report bugs or breaches when you are already looking at how the company fixes them.

Cut Implementation Time in Half

If you want to learn how to implement ISO 27001 with this kind of practical logic, check out my ISO/IEC 27001 Lead Implementer course.

We don’t just read through the clauses. We look at how to build a security framework that actually fits a real business. You will learn how to interpret the requirements, connect the dots between different controls, and implement a system that passes audits without slowing down operations.

Enroll today

Subscribe now

You’ve just been put in charge of “cybersecurity documentation.” Your boss wants policies. The auditors are asking for procedures. The IT team is talking about standards.

Where do you even begin? It’s a confusing mess of terms that all sound the same.

Most people see this as bureaucratic paperwork, digital dust piling up in a shared drive. But it shouldn’t be that way. A well structured documentation is the single best way to influence how staff and the organization as a whole work towards their objectives.

The problem is that most people, even inside large companies, don’t know how to distinguish them and can’t use them to their fullest potential.

The policies, standards, and procedures in a cybersecurity documentation follow a top-down hierarchy. Each one answers a simple, specific question. This hierarchy is the backbone of major compliance frameworks, including the ISO/IEC 27000 series, or frameworks by NIST.

If you understand this structure, you can understand how any company really works—or build the structure yourself from scratch.

The structure is simple:

• Policies answer: “Why?”

• Standards answer: “What?”

• Procedures answer: “How?”

• Records prove the above

That’s it. That’s the entire system.

To make this clear, we’ll use one simple example from start to finish: data backup.

The “Why” — The Policy

A policy is the starting point. It is a high-level, mandatory statement from management. It answers the question, “Why are we even doing this?”.

A policy doesn’t give you technical details. It doesn’t name software or list server locations. Instead, it states a clear goal and grants the authority to get it done. In the language of compliance, it “establishes management’s intent”.

This is the document that a Chief Information Security Officer (CISO) uses to get a budget. It’s the “because the CEO and the board said so” document.

In the context of the ISO 27000 family, policies are the foundation of the entire Information Security Management System (ISMS). They are the top-level directives that all other rules flow from.

It’s worth noting that while this “Why, What, How” structure is a common hierarchy , different frameworks use different terms. The U.S. National Institute of Standards and Technology (NIST), for example, primarily focuses on ‘policies’ and ‘procedures’. In the NIST world, policies themselves are often tiered, broken down by their function, such as mission-level, business-process-level, and system-level policies.

Example: The Backup Policy

A backup policy is the perfect example. It won’t tell you how to back up data. It tells you why we back up data. A good one includes two main parts:

1. Purpose (The “Why”): It states the goal.

   • Real-world example: “The purpose of this policy is to maintain data integrity and availability... to prevent data loss... and to facilitate the restoration of... business processes”.

   • Or more simply: “Data backup is an integral part of disaster recovery planning”.

2. Scope (The “Who” and “What”): It defines who and what is covered.

   • Real-world example: “This Data Backup Policy applies to: IT infrastructure... Cloud or Third-Party hosted infrastructure... [and] Information Systems that process or store OU data”.

   • And: “This policy applies to all employees, contractors, and third-party employees... who... have access to the IT assets of the organization”.

That’s it. The policy is intentionally broad. It just set the goal: we must protect our data to keep the business running.

But it’s not actionable. You can’t “audit” a goal. You need a rule.

That brings us to the standard.

The “What” — The Standard

If the policy is the “why,” the standard is the “what.”

A standard is the “what” that we must do to meet the “why”. It translates the policy’s high-level goal into a mandatory, measurable, and quantifiable rule.

A quick note on terminology: In the ISO 27001 series, these measurable, granular rules are often referred to as “topic-specific policies”. For example, you might not have a “password standard” but a “topic-specific policy for access control”. Don’t let the name fool you. If it’s a mandatory, measurable rule that defines what to do (like encryption types or backup frequency), it’s acting as a standard.

This is the bridge from intent to action. It’s a “mandatory, specific requirement that defines what is needed to comply with a policy”.

A standard helps to enforce the statements of a policy.

Example: The Backup Standard

Our policy said, “we must protect our data”. The standard answers, “OK. What does ‘protect’ actually mean?”

The rules look like this:

• The 3-2-1 Rule: This is the most famous data backup standard in the world. It’s a simple, clear, and measurable rule. As defined by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the 3-2-1 rule is :

  • 3 – Keep three copies of any important file (one primary and two backups).

  • 2 – Keep the files on two different media types (e.g., an internal hard drive and a cloud service).

  • 1 – Store one copy off-site (outside your home or business).

• Frequency: “Daily backups must be performed for all the components of critical systems”.

• Retention: “System state backups must be retained for no less than 90 days and no more than one year”.

• Testing: “Backup media must be tested periodically and at least once a year to ensure it meets... specifications... and functions as intended”.

• Access: “Access... to backups, backup media... and restoration capabilities must be restricted and limited to authorized users only”.

See the difference? These are rules you can audit. An auditor doesn’t ask, “Do you believe in backups?” (the policy). They ask, “Show me your 90-day retention logs” and “Show me the test results from your last off-site restore” (the standard).

This is the document that forces a company to stop talking and start doing.

But it still doesn’t tell an employee how to do the test.

That brings us to the procedure.

The “How” — The Procedure

If the policy is the “why” and the standard is the “what,” the procedure is the “how.”

A procedure is the “how-to” guide. It is a detailed, step-by-step instruction manual that tells an employee exactly how to follow the standard.

The definition is beautifully simple. An official ISO glossary defines a procedure as: “A detailed description of the steps necessary to perform specific operations in conformance with applicable standards”.

This is the ground-level document. It’s the “recipe”. It’s the only document of the three that a non-managerial employee actually uses to do their job.

And in the event of a crisis, it is the most important document in the company.

Example: The Backup Procedure

Let’s follow the chain:

• Policy (Why): “We must be able to restore business processes”.

• Standard (What): “We must test our restores at least once a year”.

• Procedure (How): “Here is the 9-step checklist for IT staff to perform the annual restore test.”

A real procedure for data restoration, based on university and IT documentation, looks like this :

1. IT Staff will determine the time and date of the lost data.

2. IT Staff will determine the appropriate backup media to restore the data.

3. IT Staff will insert the backup media into the appropriate server.

4. IT Staff will invoke the Backup/Restore software (e.g., Veritas Backup Exec or Arcserve).

5. IT Staff schedule the restore of the appropriate data within the Backup/Restore software.

6. IT Staff monitor the restore of data.

7. Upon restore, IT Staff evaluate the integrity of the restored data.

8. IT Staff will contact the end-user of the data to finalize restore.

9. Upon approval from the end-user, the restore is considered finished.

This is not a high-level goal. It’s a checklist. It’s ground-level, actionable, and vital.

With procedures we make sure that the rules, defined in our standards are operationalised.

The “Proof” — The Records

If the procedure is the “how-to” guide, the record is the “proof of work.”

A record is the evidence that a policy was followed, a standard was met, and a procedure was executed. It’s the log file, the completed checklist, the signed form, or the audit trail that proves an action took place.

This is the single most important part of an audit. An auditor doesn’t just read your procedure; they ask for the records to prove you followed it. This documentation provides the “chronological trail of system activity” that compliance bodies need to see.

Let’s complete our backup chain:

• Policy (Why): “We must be able to restore business processes”.

• Standard (What): “We must test our restores at least once a year”.

• Procedure (How): “Here is the 9-step checklist for IT staff to perform the annual restore test.”

• Record (Proof): “Here is the completed, backup job, on our backup server.

All together, this is the evidence that creates accountability.

Why This Matters to You

This hierarchy isn’t just for auditors. It’s a diagnostic tool for anyone.

When you’re looking at a company (as an employee, an investor, or a customer), you can use this framework to see if they’re serious about security or just paying lip service.

• Policy with no Standard? This is a “Culture of Intent.” Management has “all talk, no action.” They’ve stated a goal but have no measurable rules to make it happen.

• Standard with no Procedure? This is a “Culture of Ticking Boxes.” The company has a rule, but they’ve never created a step-by-step guide for anyone to actually follow it. The rule exists for an audit, but it’s not part of the daily operation.

• All three are aligned? That is a “Culture of Maturity.” It shows that a high-level goal (the “why”) has been successfully translated into a measurable rule (the “what”) and a ground-level checklist (the “how”).

So, the next time you hear about cybersecurity documentation, don’t think of it as “just paperwork.”

Think of it as a “Why, What, How” chain. It’s the blueprint of the company’s true priorities. And now you know how to read it.

Whenever you’re ready, there are 3 ways how we can help you:

1. ISO/IEC 27001 Lead Implementer Course: Learn how to implement, and maintain an ISMS. Leverage ready-to-use templates designed to accelerate your certification journey.

2. Exam Vouchers: Prepare and certify with confidence. Purchase exam vouchers and add official, exam-aligned training material. Save 10% compared to official retail prices.

3. Promote your business: Put your company in front of 7,000+ highly-engaged GRC professionals at a 51% open rate!

And then, the auditor looks up from their notes.

“Can you show me your documented list of internal and external issues?”

Your stomach drops. You know you talked about those issues. You had a whole workshop. You have notes in a Confluence page somewhere... or maybe they were just on a whiteboard. Is this it? Is this the “major nonconformity” that’s going to fail your audit?

The auditor helpfully adds, “You know, for Clause 4.1. Understanding the organization and its context.”

You nod, but you’re already scrambling.

This happened to all of us.

But what if I tell you that you don’t have to have a documented list of internal and external issues? Let’s dive in.

What Many of us Get Wrong

According to ISO/IEC 27001:2022, Clause 4.1 requires your organization to determine these issues.

It does not say you must document them.

To “Determine” means you have to think about them, identify them, and understand them. The activity is what’s mandatory. An artifact, something like a single, formal, signed-off document, is not.

So why do auditors ask for it?

Because it’s easy. It’s the simplest way for them to get evidence that the activity happened. Many auditors live by the old saying, “If it’s not written down, it didn’t happen”. Asking for a document is faster than a 10-minute interview and a lot easier to submit as objective evidence.

But in this specific case, the standard is on your side.

Let’s say one of your internal issues (Clause 4.1) is that you run an old, unsupported legacy system in the basement. This will of course affect multiple aspects of your management system, especially the required competence of IT-administrators.

Instead of requesting a list of internal and external issues, auditors should look out for whether an organization is taking this into consideration when it comes to hiring new and training existing staff. In this example, the internal and external context would be extremely relevant for Clause 7.2 (Competence).

So, the problem isn’t always the standard. It’s the gap between the standard’s flexibility and the auditor’s traditional, document-centric habits.

What a “Nonconformity” Actually Is (And Isn’t)

Before we go further, we need to agree on what “failing” means. When an auditor finds something wrong, they raise a “nonconformity.”

A nonconformity is simply the “non-fulfilment of a requirement”.

This is the most important thing you will read today: In any audit, the auditor is checking for the fulfilment of two sets of requirements. Not just one.

1. ISO 27001 Requirements. These are the “shall” statements in the ISO 27001 standard. For example, Clause 5.2 says you shall establish an information security policy. If you don’t have one, that’s a nonconformity. This is the obvious one.

2. Organizational Requirements. These are the rules, policies, and procedures you write for yourself. If your Information Security Management System (ISMS) says you will do something, the auditor will check that you are, in fact, doing it.

👉 An auditor can only write a nonconformity if you violate a rule from one of these two sets.

So, if the standard doesn’t require a documented list (Set 1) AND your own ISMS policies don’t promise a documented list (Set 2)... then the absence of that list is not a nonconformity.

The Trap: How You Create Your Own Nonconformities

That second set of requirements—the ones you write yourself—is the biggest trap in compliance. And most people walk right into it.

We try to “over-document” to look good, but we just give the auditor more ammunition.

Let’s use an example. The standard requires you to “manage information security incidents.” That’s flexible. But you, trying to be impressive, write a mandatory company-wide procedure that says, “All incidents, of any severity, must be reported to the CISO within 15 minutes.”

You’ve just created a new, very specific, and very brittle requirement for yourself.

What happens when the auditor finds an employee who reported an incident after 30 minutes? You didn’t violate the standard, but you did violate your own procedure. And that is a 100% valid nonconformity.

This is the “Self-Imposed Requirement Trap.” It’s born from good intentions but paved with nonconformities. We write aspirational policies that don’t match our real-world operations.

This is why Clause 4.1 is such a perfect example. By not documenting it formally, you may reduce your audit risk—as long as you still did the work and can prove it. If you do document it, you’ve just created more administrative overhead, and thus, more ways to fail.

Why Doesn’t the Standard Just Tell Me What to Write Down?

At this point, you might be thinking, “This is silly. Why don’t the ISO people just give us a checklist?”

The answer is that modern standards like ISO 27001 are risk-based, not checklists. They are designed to work for a 10-person startup and a 100,000-person bank. The standard cannot know the “extent of documented information” you need. Only you can.

The standard trusts you to be the expert on your own company. It’s built for effectiveness, not just “a system of documents”.

But the standard isn’t trying to trick you. In fact, it has a “secret code” for when it absolutely, 100% wants you to write something down.

You just have to know the two magic phrases:

• “Maintain documented information”: This is the code for a document. Think of policies, procedures, or the scope of your ISMS. These are “living” documents that you must “maintain” and keep up-to-date.

• “Retain documented information”: This is the code for a record. This is evidence, or proof, that something happened. Think of audit results, management review outputs, or logs. You “retain” them to prove you did the work.

Now, go back and look at Clause 4.1. Does it say “maintain” or “retain”?

It says neither. It just says “determine.”

This is the standard’s authors explicitly telling you that the format is flexible. When they want a document, they know exactly what to say.

What ISO 27001 Actually Requires

So, let’s put this “secret code” to work. You don’t need a 50-page “Mandatory Documents” list. The standard is actually very specific. Here is a list of the main things ISO 27001:2022 explicitly requires you to document.

(And before you start the audit, just look at this list. Notice what isn’t on it? Clause 4.1.)

This isn’t everything: The most important one is to be found in clause 7.5: the documents you decide are necessary. That’s the trap from Section 4. Be thoughtful. Keep it simple.

The Bottom Line

That’s it. You’re not at the mercy of an auditor’s personal checklist. An audit is a verification of your system, not a test of your document library.

Your job is to build an effective Information Security Management System that actually manages risk. Part of that is having the right documentation—and not one page more than you need.

So be polite. Be confident. And most importantly, know the difference between what the standard requires, and what you promise.

Whenever you’re ready, there are 3 ways how we can help you:

1. ISO/IEC 27001 Lead Implementer Course: Learn how to implement, and maintain an ISMS. Leverage ready-to-use templates designed to accelerate your certification journey.

2. Exam Vouchers: Prepare and certify with confidence. Purchase exam vouchers and add official, exam-aligned training material. Save 10% compared to official retail prices.

3. Promote your business: Put your company in front of 7,000+ highly-engaged GRC professionals at a 51% open rate!

Share GRC Lab

What I usually find is a big spreadsheet that includes a a direct copy-paste of ISO 27001’s Annex A, with three extra columns added:

1. Applicable? (Yes/No)

2. Implementation Status (Implemented/Not Implemented)

3. Justification for inclusion/exclusion

But what’s the point of having a SoA?

An ISO 27001 certificate proves that an ISMS was established that meets the requirements of the standard and is capable of achieving the defined information security objectives. Given it’s descriptive nature, being compliant with ISO 27001 doesn’t provide much information about how secure an organisation actually is.

The SoA is supposed to be the key document that gives the certificate context. It’s meant to tell you what’s really going on inside that certified ISMS. It’s the one place that should explain how a company is managing its specific security risks and describe what has actually been done to treat them.

The problem is, most SoAs don’t.

I see this document, which should be the beating heart of the ISMS, treated as a simple administrative hurdle.

This “compliance-first” approach, where you just fill out the Annex A spreadsheet, misses the entire point of the SoA, and it’s probably not compliant with what the standard’s authors intended.

What ISO 27001 Actually Requires

Let’s look at what the standard (in clause 6.1.3) actually requires. It says the organization must:

1. Determine all controls that are necessary to treat its risks.

2. Compare those necessary controls with the ones in Annex A to verify that no necessary controls have been omitted.

3. Produce a Statement of Applicability that contains the necessary controls, the justification for including them, their implementation status, and the justification for excluding any Annex A controls.

The key phrase here is “necessary controls.”

The order here is critical, and it’s the part most people get backward. The standard explicitly asks you to start with your risks and your controls. The comparison to Annex A comes after you’ve done that hard work, not before.

But almost everyone jumps straight to Annex A and works backward, which defeats the entire risk-based purpose of the standard.

Your SoA is supposed to be a list of your necessary controls, not just a report card for Annex A.

Annex A Is Not Your Control Catalog

This is the core misunderstanding. People treat Annex A as a comprehensive control catalog. It isn’t.

What is Annex A? It’s a list of 93 reference controls, organized into four themes. Think of it as a safety net, a final checklist to sanity-check your risk assessment and make sure you didn’t forget an entire category of security.

It is not a detailed “how-to” guide.

Let’s use an example. Look at control A.8.5, “Secure Authentication.” The standard says:

“Secure authentication technologies and procedures shall be implemented based on information access restrictions and the topic-specific policy on access control.”

That’s it. It’s a broad description of a desired state. It doesn’t tell you what technologies to use, how to configure them, or where to apply them. It’s merely a high-level goal.

The standard has to be this way because “secure authentication” means something very different for a global bank than it does for a small internal-only manufacturing tool. The risk is different, so the necessary control will be different.

Annex A is just a prompt. It asks, “Have you thought about authentication?” Your risk assessment must provide the detailed answer. You can’t “implement” A.8.5. You implement actual security controls that help you achieve the goal of A.8.5.

So, What Are “Necessary Controls”?

“Necessary controls” are the specific measures and technologies you decide to implement to treat your risks.

The “necessary” part is the direct output of your risk treatment plan. If your risk assessment says ‘phishing-based account takeover, is unacceptably high,’ your risk treatment plan might be ‘Reduce this risk.’ The how—the specific action you take—that’s your necessary control.

Let’s stick with the authentication example. Your risk assessment identifies that high risk of account compromise. To treat that risk, you determine a “necessary control” is needed.

That control isn’t “A.8.5.” Your necessary control is something specific and actionable, like:

• “Implement hardware security keys (YubiKey) for all administrator accounts.”

• “Enforce MFA authenticator apps (TOTP) across all cloud services.”

• “Implement SAML-based Single Sign-On (SSO) with session timeouts and IP-based restrictions.”

• “Use certificate-based authentication for all machine-to-machine access.”

See the difference? These are real, specific, and auditable actions. You can test these. You can verify they are configured correctly. These are your “necessary controls.”

What Your SoA Should Look Like

This changes how your SoA should be structured. The document shouldn’t just list the 93 Annex A controls. It should list your specific controls and map them back to Annex A.

Instead of this common (and less useful) approach:

Your SoA should look more like this, starting with your controls:

Necessary Control ID: e.g. CTR-001

Necessary Control: Access to all critical systems is protected with MFA.

Justification for Inclusion/Exclusion: This control has been identified as necessary to treat one or more identified risks

Status: Implemented

Reference: A.8.5

Where to go from here.

Your SoA is a living document. When it’s built this way, it’s no longer just an audit document. It becomes a central governance tool. It tells an auditor, a customer, or a new CISO exactly what you are doing to manage your risks.

It’s what you use to guide internal audits. It’s what you show new security team members to get them up to speed. It’s a concrete, detailed summary of your security program that you can use to build trust with customers, far more effectively than just showing them the certificate.

While most auditors (including myself) accept SoAs with the Annex A copied, doing what the standard actually has in mind, can greatly benefit your organisation and help build the type of trust you seek to establish.

I think you should consider to upgrade your SoA!

But there’s often a crucial layer missing from this formal documentation pyramid: the process. While procedures are a core component of the pyramid, processes are frequently left undocumented. This isn’t because they are unimportant; in fact, they are vital for understanding the big picture. The reason they are often omitted is that a process isn’t a document itself—it’s the action, the end-to-end flow of work that delivers a result.

Let’s break down why that is, starting with what a process truly represents.

What is a Process? The Strategic “What” and “Why”

A process is a high-level series of related activities that transforms an input into a valuable output. It answers the questions, “What needs to be done?” and “Why are we doing it?”.

According to ISO 9000:2015, a process is defined as:

“A set of interrelated or interacting activities that uses or transforms inputs to deliver a result.”

A process provides the overall framework and direction but doesn’t get into the granular, step-by-step details. It’s the strategic roadmap, not the turn-by-turn directions.

Example: The Incident Management Process

A perfect example is the Incident Management Process. This is the entire lifecycle for handling a security event, from initial alert to final resolution. The goal (the “why”) is to minimize damage and restore normal operations as quickly as possible. The process (the “what”) is a sequence of high-level activities. According to frameworks from SANS, ISO and NIST, these activities typically include :

1. Preparation: Getting ready before an incident occurs.

2. Identification (or Detection & Analysis): Recognizing that an incident has happened and figuring out its scope.

3. Containment: Stopping the incident from spreading and causing more damage.

4. Eradication: Removing the threat from the environment.

5. Recovery: Restoring affected systems back to normal operation.

6. Lessons Learned (or Post-Incident Activity): Reviewing the incident to improve for the future.

This sequence describes the entire flow of work. It tells you what needs to happen, but it doesn’t tell you exactly how to perform each of these activities. For that, you need procedures.

What is a Procedure? The Tactical “How”

A procedure on the other hand is a detailed, step-by-step set of instructions that explains how to perform a specific activity within a process. It answers the questions, “Who does what, when, and how?”.

According to ISO 30000:2009, a procedure is defined as:

“A specified way to carry out an activity or a process.”

Unlike a process, which is flexible, a procedure is intentionally rigid and prescriptive to ensure tasks are performed with consistency and precision every time. You can’t have a procedure without an underlying process, but a process can exist without a documented procedure.

Example: Procedures within the Incident Management Process

Let’s zoom in on our Incident Management Process and see the specific procedures that bring each activity to life.

Activity: Identification

• Procedure: End-User Reporting a Phishing Email. This document would give an employee exact, step-by-step instructions:

  1. Do not click any links or open any attachments in the suspicious email.

  2. If you are using Microsoft Outlook, click the “Report Phishing” button on the Home ribbon.

  3. Alternatively, forward the email as an attachment to abuse@yourcompany.com.

  4. If you accidentally clicked a link or entered your password, immediately call the IT Help Desk at extension 5555 and report it.

Activity: Containment

• Procedure: Isolating a Compromised Host from the Network. This is a technical guide for a security analyst, detailing the precise actions to take once a machine is confirmed to be infected:

  1. Open the Cortex XDR console and locate the compromised endpoint by its hostname.

  2. Right-click the endpoint and select “Isolate Endpoint” from the action menu.

  3. If the endpoint is a Linux server, log in to the firewall administration panel.

  4. Create a new rule to block all inbound and outbound traffic for the server’s IP address, except for connections from the security team’s designated IP range.

Activity: Lessons Learned

• Procedure: Conducting a Post-Incident Review. This procedure ensures that every incident review is thorough and consistent. It would instruct the Incident Commander to:

  1. Schedule a post-incident review meeting within 48 hours of the incident’s resolution.

  2. Complete the official “Post-Incident Review Template” document.

  3. In the “Incident Timeline” section, document the key actions taken in chronological order.

  4. In the “Root Cause Analysis” section, identify the primary cause and any contributing factors.

  5. In the “Action Items” section, create a task list with assigned owners and due dates for all preventative measures identified.

As you can see, the process provides the high-level framework, while the procedures provide the detailed, actionable instructions needed to execute each part of that framework correctly and consistently.

Sample Lecture

Here is a sample lecture of our ISO/IEC 27001 Lead Implementer course on the fundamentals of documented information in the context of clause 7.5 of ISO/IEC 27001:2025.

Whenever you’re ready, there are 3 ways how we can help you:

1. ISO/IEC 27001 Lead Implementer Course: Learn how to implement, and maintain an ISMS. Leverage ready-to-use templates designed to accelerate your certification journey.

2. Exam Vouchers: Prepare and certify with confidence. Purchase exam vouchers and add official, exam-aligned training material. Save 10% compared to official retail prices.

3. Promote your business: Put your company in front of 7,000+ highly-engaged GRC professionals at a 51% open rate!

This was not merely an accumulation of talent; it was the strategic assembly of a “superteam.” Each player brought a distinct, elite skill set: Wade, the established champion and explosive scorer; James, the versatile, do-it-all MVP; and Bosh, the adaptable big man who could stretch the floor. Together, they created a synergistic force that dominated the league, reaching the NBA Finals in all four of their seasons together and winning two championships. If it wasn’t for Dirk Nowitzki, this team could have been the most successful ever assembled.

Today, in the world of governance, risk, and compliance, a similar “Big Three” has emerged. The convergence of data-driven business models, the rapid rise of artificial intelligence, and a complex web of global regulations has created the need for a new kind of strategic alignment.

Organizations can no longer treat information security, AI governance, and data privacy as separate disciplines. To build and maintain trust in the modern digital economy, they need an integrated playbook. This playbook is defined by a trio of powerful ISO management system standards.

The ISO “Big Three”

• ISO/IEC 27001: This is the established champion, the bedrock of the team. As the international standard for an Information Security Management System (ISMS), ISO 27001 provides a comprehensive, risk-based framework for protecting the confidentiality, integrity, and availability of all organizational information. It is not just about IT security; it encompasses people, processes, and technology to manage information risks effectively.

• ISO/IEC 42001: This is the versatile, forward-looking standard that adapts to the new reality. ISO 42001 specifies the requirements for an Artificial Intelligence Management System (AIMS), addressing the unique risks and opportunities presented by AI. It provides a structured approach to managing the entire AI lifecycle, from design and development to deployment and decommissioning. The standard focuses on promoting responsible AI use by tackling challenges like ethical considerations, transparency, accountability, and bias mitigation, ensuring that innovation happens within a controlled and trustworthy framework.

• ISO/IEC 27701: This is the standard that completes the team. ISO 27701 specifies the requirements for a Privacy Information Management System (PIMS). It takes the robust security foundation of ISO 27001 and applies a specific, rigorous focus on the protection of personally identifiable information (PII). A PIMS provides the blueprint for complying with a growing number of global privacy regulations, most notably the EU’s General Data Protection Regulation (GDPR).

The assembly of these three standards marks a significant evolution in enterprise risk management. It signals a move away from siloed compliance activities and toward an integrated governance model. The business environment is now defined by the interplay of data operations (requiring security), AI tools (requiring AI governance), and privacy obligations (requiring privacy management).

These are not separate challenges; they are interconnected facets of a single, overarching question: how can an organization use data and technology responsibly to create value?

This trio of standards provides the market with a holistic, internationally recognized, and auditable “Trust Framework.” Companies are no longer just selling a product or service; they are selling trust. The ISO “Big Three” provides the definitive blueprint for demonstrating it. This shift will inevitably drive a convergence of roles within organizations, requiring Chief Information Security Officers, Chief Privacy Officers, and emerging Chief AI Officers to work from a common playbook.

Subscribe now

Why ISO 27701:2019 Was Sidelined

For any championship team to function, its key players must be on the court and in sync. For the past few years, a critical member of the governance “Big Three” was effectively stuck on the bench due to a technicality. The 2019 version of ISO 27701, while conceptually powerful, was hampered by a structural dependency that rendered it incompatible with the latest security best practices.

The original ISO 27701:2019 was designed not as a standalone standard, but as a privacy extension to ISO 27001. Its entire structure was built upon the foundation of an existing Information Security Management System (ISMS). The PIMS it described borrowed its core security controls directly from the Annex A of the then-current version of the security standard, ISO 27001:2013. This tight coupling was its greatest strength and, ultimately, its critical weakness.

In October 2022, the foundational standard, ISO/IEC 27001, received a major update to its 2022 version. This was not a minor revision. The update completely restructured the heart of the standard: the Annex A security controls. The old framework of 14 domains and 114 controls was replaced with a more modern structure of 4 themes and 93 controls. More importantly, 11 new controls were introduced to address contemporary threats such as insecure cloud configurations, the need for proactive threat intelligence, and the prevention of data leakage.

This created a technical impasse. ISO 27701:2019 was hardwired to the old, outdated 2013 control set. Its clauses directly referenced control numbers and structures that no longer existed in the new ISO 27001:2022 standard. As a result, organizations that proactively transitioned their ISMS to the new 2022 security standard found themselves in a compliance paradox. While they had a state-of-the-art security program, it was technically impossible for them to obtain an accredited ISO 27701 certification. The two standards were simply out of sync, making a unified audit against both impossible. This wasn’t a theoretical problem; it created real business friction for companies needing to demonstrate both leading-edge security and privacy compliance in contracts and tenders.

The delay in resolving this issue was further complicated by a behind-the-scenes dependency. The update to ISO 27701 could not be released until its own supporting standard, ISO/IEC 27706, was also overhauled. ISO 27706 is the standard that defines the requirements for the bodies that audit and certify PIMS. In essence, the rules of the game (27701) could not be updated until the rulebook for the referees (27706) was rewritten to match.

This multi-year standards logjam left the industry in a state of compliance limbo, highlighting the inherent fragility of a tightly coupled extension model where standards evolve at different paces. The challenges born from this experience have directly informed the more resilient, independent structure of the new 2025 revision.

A Deep Dive into the ISO 27701:2025 Update

The release of ISO/IEC 27701:2025 resolves the technical misalignment and introduces significant structural improvements that make the standard more flexible, accessible, and relevant to modern business challenges. It is now fully aligned with ISO 27001:2022 and brings a new level of maturity to privacy management.

Merged Annexes for Controllers and Processors

The 2019 version of the standard separated its privacy-specific controls into two different annexes: one for PII Controllers and another for PII Processors. The 2025 revision merges these into a single, consolidated Annex A, organized into Table A.1 (for PII Controllers) and Table A.2 (for PII Processors).

This change reflects the complex reality of modern data processing. Many organizations, particularly in the cloud and SaaS industries, operate as both a controller and a processor. They act as a controller for their own employee and direct customer data, while simultaneously acting as a processor for the data their clients upload and manage using their service. The previous structure could lead to duplicative documentation and a more cumbersome audit process. The new, consolidated annex simplifies implementation for these dual-role organizations, allowing for a more streamlined and logical approach to defining and applying privacy controls. Across these two tables, a total of 49 privacy-specific controls remain.

Table A.3 and the Standalone PIMS

Perhaps the most impactful change in the 2025 version is the introduction of a new Table A.3 in Annex A. This table contains a set of 29 parsed security controls specifically for organizations that do not have an established ISMS certified to ISO 27001.

This is a fundamental shift. It transforms ISO 27701 from a simple “add-on” into a certifiable, standalone management system. Previously, an organization had to endure the significant time and resource investment of a full ISO 27001 implementation before it could even begin the ISO 27701 certification process. Now, an organization whose primary risks and market drivers are centered on privacy can pursue a PIMS certification directly. This makes an internationally recognized privacy certification far more accessible to a wider range of businesses, including startups and small-to-medium-sized enterprises that may have been deterred by the cost and complexity of the prerequisite. This change will likely reshape the privacy certification landscape, creating a new, more attainable entry point and increasing the competitive expectation for all companies handling personal data to seek formal certification.

Considering Climate Change in Your Privacy Program

In line with the 2021 ISO London Declaration, which commits to incorporating climate science into all international standards, the new ISO 27701 includes a requirement to consider climate change. This is not an abstract environmental pledge; it is a concrete risk management requirement embedded into the core of the management system.

The amendment adds new text to two key clauses:

• Clause 4.1 (Understanding the organization and its context): “The organization shall determine whether climate change is a relevant issue.”

• Clause 4.2 (Understanding the needs and expectations of interested parties): A new note clarifies that “Relevant interested parties can have requirements related to climate change.”

This forces organizations to analyze how climate change could impact their ability to protect PII.

Consistency is Key: What Stays the Same

Despite these significant updates, the core philosophy of the standard remains intact. The risk-based approach is still central. Organizations must still use a Statement of Applicability (SoA) to document which controls from Annex A are implemented and to provide a justification for any that are excluded based on the organization’s role as a PII controller or processor [User Query]. This ensures that the PIMS remains tailored to the specific privacy risks and context of each organization.

ISO 27701 and the GDPR Landscape

One of the most powerful drivers for adopting ISO 27701 is its close alignment with the requirements of the GDPR. However, it is crucial to understand the distinction between a management system certification and a formal, legal certification under the GDPR itself. Confusing the two can lead to significant misinterpretations of an organization’s compliance status.

ISO 27701 serves as an excellent operational framework to help an organization meet its GDPR obligations. The standard’s annexes provide a direct mapping of its privacy controls to the specific articles of the GDPR, offering a clear and practical roadmap for implementation. Achieving ISO 27701 certification is a powerful way to demonstrate adherence to the GDPR’s core principle of “accountability,” which requires organizations to not only comply with the regulation but also be able to prove it.

This, however, is not the same as an official GDPR certification as envisioned under Article 42 of the regulation. Article 42 outlines a mechanism for creating approved “data protection certification mechanisms, seals and marks”. An Article 42 certification would be issued by an accredited body based on criteria formally approved by a country’s national Data Protection Authority (DPA). Such a certification would attest that a specific data processing operation—for example, a particular software product or service—conforms to the GDPR’s legal requirements.

An ISO 27701 certification is different in nature and scope. It is an attestation from an accredited certification body that the organization has successfully implemented and maintains a management system to systematically identify, assess, and treat privacy risks. It is a globally recognized best-practice standard for process maturity, not a legal instrument created under the authority of the GDPR.

The slow and complex process of establishing official Article 42 certification schemes has meant that very few have been approved across Europe since the GDPR was enacted. This regulatory vacuum has inadvertently elevated the market importance of ISO 27701. In the absence of official GDPR “seals,” businesses needed a reliable and internationally understood tool to demonstrate privacy diligence in contracts, RFPs, and vendor assessments. ISO 27701 has filled that role, becoming the de facto global standard and the primary mechanism for organizations to provide assurance about their privacy governance.

Your Transition and Next Steps

The new ISO/IEC 27701:2025 standard is available for implementation immediately. For organizations looking to adopt it or transition from the previous version, a clear game plan is essential.

The Transition Clock

For organizations already certified to ISO 27701:2019, a formal transition period is now in effect. Typically, ISO allows up to 36 months for such transitions. However, the definitive deadline will be established by the International Accreditation Forum (IAF) in an official Mandatory Document (MD). Given that the supporting audit standard, ISO 27706, was published in parallel with the main standard, this transition period may be shorter than the typical three years. Regardless of the final date, all certifications to the 2019 version will expire or be withdrawn at the end of this period, making a timely transition mandatory to maintain certification.

Actionable Advice for Your Organization

The right approach depends on your organization’s current certification status.

1. If You Are Currently Certified to ISO 27701:2019: Your immediate priority is to plan the transition. Begin by conducting a thorough gap analysis to compare your existing PIMS against the new 2025 requirements. Key areas of focus should be the restructured Annex A controls, the integration of the new climate change considerations into your context and risk assessment processes, and any necessary updates to your Statement of Applicability. Contact your certification body to schedule a transition audit, which can often be combined with your next planned surveillance or recertification audit to improve efficiency.

2. If You Are Certified to ISO 27001:2022 and Want to Add Privacy: You are in an ideal position. The new ISO 27701:2025 is specifically designed to align seamlessly with your existing ISMS. The technical conflicts of the past have been eliminated. You can now extend your current management system to incorporate the PIMS requirements, leveraging your established risk assessment methodologies and security controls as a strong foundation for your privacy program.

3. If You Are New to ISO Privacy Standards: You now face a strategic choice that did not exist before. You can pursue the new standalone PIMS certification by implementing the core security controls outlined in Table A.3. This is a more direct and potentially less resource-intensive path to a recognized privacy certification. Alternatively, you can pursue the “gold standard” approach: implementing a full ISMS according to ISO 27001:2022 first, and then integrating the PIMS via ISO 27701:2025. The best path depends on your organization’s specific risk profile, resources, market demands, and long-term strategic goals.

Ultimately, the transition to ISO 27701:2025 should be viewed as more than a simple compliance deadline. It presents a strategic opportunity for organizations to re-evaluate and mature their entire privacy program. The mandatory review forced by the transition is a catalyst to ask deeper questions. Is our privacy risk assessment process robust enough to handle emerging threats from AI? Have we adequately considered the resilience of our PII processing against plausible climate-related disruptions? Companies that treat this transition as a strategic review will emerge with a stronger, more resilient, and more valuable privacy program. Those that view it as a purely administrative task may achieve certification but will miss the chance to genuinely improve their posture, leaving them more exposed to the risks of tomorrow.

Whenever you’re ready, there are 3 ways how we can help you:

1. ISO/IEC 27001 Lead Implementer Course: Learn how to implement, and maintain an ISMS. Leverage ready-to-use templates designed to accelerate your certification journey.

2. Exam Vouchers:

   Prepare and certify with confidence. Purchase exam vouchers and add official, exam-aligned training material. Save 10% compared to official retail prices.

3. Promote your business: Put your company in front of 7,000+ highly-engaged GRC professionals at a 51% open rate!

Some of you might remember Jacob from his GRC Academy Podcast, which was the very first podcast I was invited to join. He’s an excellent educator, and I’m very happy that he has agreed to write this guest edition of GRC Lab.

In the article below, Jacob shares his insights on CMMC and its impact on organizations today.

—

After so many years of waiting CMMC is finally here!

The United States Department of War (DoW) released the Cybersecurity Maturity Model Certification (CMMC) final acquisition rule on September 10, 2025 and it becomes effective on November 10, 2025.

Let’s dive into what CMMC is and what happens next!

How did we get here?

Foreign adversaries have been compromising DoW contractor networks and stealing information about critical DoW programs for years.

The department responded by creating contractual clauses focused on the implementation of NIST 800-171’s security controls. NIST 800-171 outlines the controls necessary to protect Controlled Unclassified Information (CUI) on non-government systems.

DFARS 252.204-7012 required contractors to:

• Implement NIST 800-171 no later than December 31, 2017

• Report cyber incidents within 72 hours

• Use FedRAMP moderate “equivalent” cloud service providers when they hold CUI

The DoW soon discovered that contractors were still not implementing the security controls, so the DoW created provision DFARS 252.204-7019 and contract clause DFARS 252.204-7020.

DFARS 252.204-7019 requires the contractor to submit a NIST 800-171 self-assessment score to DoW to be eligible for contract award.

DFARS 252.204-7020 requires the contractor to allow the government to perform third-party cyber assessments of the contractor’s covered network.

The government has been assessing contractor networks for years under DFARS 7020, and contractors have continued to demonstrate that self-attestation of cyber compliance does not work.

How does CMMC fit into the picture?

CMMC has three levels, and the requirements vary per level:

CMMC Level 1

• Implement 15 controls

• Required for contracts with only Federal Contract Information (FCI) (no CUI)

• Contractor is required to perform a self-assessment – no 3rd-party assessment is required

CMMC Level 2

• Implement 110 controls

• Required for contracts with CUI

• Many contracts will require a CMMC level 2 certification via a 3rd-party assessment by a C3PAO

CMMC Level 3

• Implement 24 additional enhanced security controls

• Required for DoW’s most critical CUI programs

• All contracts will require a 3rd-party assessment by DIBCAC resulting in CMMC certification

  • CMMC level 2 certification is a prerequisite

Contracts/solicitations will require compliance or certification at a specific CMMC level and the government will not award a contract to a company that isn’t compliant.

The acquisition rule modifies a contractual clause called DFARS 252.204-7021 which is the contractual clause that will require either CMMC compliance or certification at a specified CMMC level.

It is estimated there are 80,000 and 300,000 companies in the Defense Industrial Base (DIB). It is impossible for the government to assess that number of companies.

CMMC expands the capacity to perform independent assessments and establishes an ecosystem of independent assessors called CMMC Third-Party Assessor Organizations (C3PAOs).

From the beginning, the DoW has been focused on protecting their information. Similar to health data in a HIPAA context, or PII in a privacy law context, FCI and CUI are the regulated information that is in scope.

What’s next?

CMMC certification assessments have been occurring since the CMMC final program rule became effective back in December of 2024. When the CMMC acquisition final rule is effective in November of 2025, the CMMC phase-in begins.

The CMMC timeline

Each phase of the CMMC rollout introduces progressively higher certification requirements, ultimately leading to full implementation by phase 4. Here’s a breakdown of the timeline:

Phase 1: Initial Requirements

• Start Date: November 10, 2025

• Requirements: contractors handling FCI and CUI will need to self-assess that they meet either CMMC level 1 or CMMC level 2 to qualify for applicable DoW contracts.

• Optional: The DoW may require CMMC level 2 certification for specific contracts or option periods.

Phase 2: CMMC Level 2 Third-Party Assessments

• Start Date: November 2026

• Requirements: DoW will mandate CMMC level 2 certification requirements for contract awards, with the flexibility to require it only during option periods.

• Optional: The DoW may begin to include CMMC level 3 certification requirements for contracts with higher security needs.

Phase 3: CMMC Level 3 Third-Party Assessments

• Start Date: November 2027

• Requirements: Both CMMC level 2 and CMMC level 3 certification will be required as conditions for new contracts and option periods.

• Optional: The DoW may delay CMMC level 3 requirements to option periods for some contracts.

Phase 4: Full Implementation

• Start Date: November 2028

• Requirements: At this final phase, CMMC requirements will apply to all applicable contracts, including those awarded prior to Phase 4.

What contractors should do now

If your company hasn’t started working on NIST 800-171 and CMMC compliance, it is time to dive in before it is too late!

Large primes are applying more pressure on their subcontractors to become certified because they will be accountable for their subcontractors’ compliance – at all tiers.

Becoming CMMC certified early in the CMMC phase in period will be a competitive advantage, but over time it will become “the norm.”

Here are a few steps you should prioritize right now

1. Determine Your Certification Level

Identify which CMMC level your organization needs based on the type of information you handle.

This step will determine the CMMC level of assessment and resources required. Plan ahead and think of the contracts you want to go after in the next three years, because CMMC level 1 will be limiting. C3PAOs can be found on the CyberAB marketplace.

2. To insource or outsource?

Does your team have the technical and cybersecurity skills to address the security controls?

If not, consider hiring a Managed Service Provider (MSP) like Summit 7 to manage your IT environment. Most MSPs are not focused on CMMC and unfortunately will be the cause of many failed CMMC assessments, so choosing the right MSP is critical!

3. Begin preparing ASAP

Estimates on how long it takes to go from 0% to 100% CMMC compliance range from 6 – 18 months. The duration varies based on the size and complexity of your organization and systems.

4. Engage with a C3PAO Early

If CMMC certification is in your future, reserve your assessment spot with a C3PAO as soon as you can. There are only 82 C3PAOs as of the time of this writing, and many of them are already booked into 2026.

5. Develop an Ongoing Compliance Strategy

CMMC certification requires annual affirmations of compliance. Set up regular reviews and training to ensure ongoing compliance.

Closing Thoughts

NIST 800-171 is the US federal standard to protect CUI.

Soon there will be a contractual clause in the FAR requiring the implementation of NIST 800-171 for federal (non-DoW) contracts. If you want to support the federal government, you will not be able to get away from these security controls.

For the sake of our nation’s security and your business’s survival, the time to comply is now.

Here’s what we got for you today:

• Next-Gen Cyber Defense: DoW Unveils New Cybersecurity Risk Management Construct

• Links to some of our most popular articles.

GRC Spotlight

Next-Gen Cyber Defense: DoW Unveils New Cybersecurity Risk Management Construct

The Department of War (DoW) has announced a significant evolution in its approach to cybersecurity with the introduction of the new Cybersecurity Risk Management Construct (CSRMC). This move marks a departure from the long-standing NIST Risk Management Framework (RMF), signaling a shift towards a more dynamic and automated approach to cyber defense.

You can read the full announcement here.

The DoW states the RMF has become "overly reliant on static checklists and manual processes that failed to account for operational needs and cyber survivability requirements." The CSRMC, in contrast, aims to enable "cyber defense at the speed of relevance required for modern warfare" by focusing on automation, critical controls, and continuous monitoring.

The New 5-Phase Lifecycle

At the heart of the CSRMC is a five-phase lifecycle that aligns with system development and operations:

• Design Phase: Security is embedded at the outset, ensuring resilience is built into the system architecture.

• Build Phase: Secure designs are implemented as systems achieve Initial Operating Capability (IOC).

• Test Phase: Comprehensive validation and stress testing are performed prior to Full Operating Capability (FOC).

• Onboard Phase: Automated continuous monitoring is activated at deployment to sustain system visibility.

• Operations Phase: Real-time dashboards and alerting mechanisms provide immediate threat detection and rapid response.

From 7 Steps to 5 Phases: A Paradigm Shift

The CSRMC's five phases represent a streamlined and more integrated approach compared to the seven steps of the NIST RMF:

RMF Steps

CSRMC Phase

1. Prepare

Phase 1: Design

2. Categorize

Phase 1: Design

3. Select

Phase 1: Design

4. Implement

Phase 2: Build

5. Assess

Phase 3: Test

6. Authorize

Phase 4: Onboard

7. Monitor

Phase 5: Operations

Key Takeaways

The introduction of the CSRMC signifies a major shift in the DoW's cybersecurity strategy, with a clear emphasis on:

• Automation: To increase the speed and efficiency of risk management.

• Continuous Monitoring: To achieve real-time situational awareness and a constant state of authorization.

• Integration: Embedding security into the development lifecycle from the very beginning (DevSecOps).

• Cyber Survivability: Enabling operations to continue even in contested cyber environments.

This new construct is not just a replacement for the RMF; it's a fundamental change in mindset, moving from a compliance-based approach to a risk-based, operational, and data-centric model. As the DoW rolls out the CSRMC, contractors and stakeholders can expect a greater emphasis on automated security solutions, real-time data, and a more agile and responsive approach to cybersecurity.

Test your Knowledge

Today’s question is from the CISM curriculum:

Which of the following is MOST important for ensuring data integrity during a disaster recovery process?

A) Encryption
B) Data validation checks
C) Backup frequency
D) Physical security measures

👉 Think you know the answer? Scroll down for the solution!

Answer: The correct answer is B.

A) Encryption is important for security but not directly related to data integrity during recovery.
B) Data validation checks ensure that the data being restored is accurate.
C) Backup frequency is important but secondary to data validation.
D) Physical security measures are important but not directly related to data integrity during recovery.

Here’s what we got for you today:

• Many professionals mistake requirements for controls when referring to the mandates found within compliance frameworks. Learn about the real difference between them.

• Our partner Kertos has secured an impressive series of 14 million Euros for redefining AI-native compliance in Europe.

GRC Spotlight

Kertos raised a €14 Million Series A!

Last year, shortly after leaving my 9 to 5, and launching my own business, I entered a strategic partnership with Kertos. Fast forward to today, Kertos has not only become my favourite client, but also an all-in-one compliance suite built for European SMEs and scaleups.

I am very proud to tell you that we have raised €14 million in a Series A funding round. The investment was spearheaded by global fintech investor Portage, with continued support from existing backers Pi Labs, Redstone, 10x Founders, and Seed + Speed Ventures.

Book a demo

Earlier this week, I posted on LinkedIn about a topic that seems to trip up even seasoned GRC professionals: the difference between a "requirement" and a "control." The post went unexpectedly viral, flooded with comments and questions that highlighted just how much confusion surrounds these fundamental terms. It’s clear this is a conversation we need to have.

So, let's do a deep dive. Understanding this distinction isn't just academic—it's the foundation of building an effective, efficient, and auditable compliance program.

Requirements: The "What"

Let's start with the basics. As per ISO 27000 a requirement is a "need or expectation that is stated, generally implied or obligatory." Frameworks like NIST CSF, ISO 27001, SOC 2, C5, and regulations like GDPR are collections of requirements. They tell you what you need to do and why it's important, but they rarely tell you how to do it.

A key concept here is that these frameworks are descriptive, not prescriptive. They describe a desired outcome (e.g., "protect data from unauthorized access") rather than prescribing the exact tool or process every organization must use. This is on purpose and by design. Descriptive frameworks, allow a five-person startup and a 50,000-person enterprise to comply with the same requirements in ways that fit their unique environments.

Controls: The "How"

If a requirement is the "what," a control is the "how." A control is the specific policy, procedure, technical safeguard, or action you implement to meet a requirement and modify risk. Controls are the concrete steps you take to get to the destination defined by the requirement.

control
“Any action taken by management, the board, and other parties to manage risk and increase the likelihood that established objectives and goals will be achieved”

A Quick History: From Accounting to Cybersecurity

To understand controls, it helps to know where the term came from. It didn't originate in IT or cybersecurity, but in finance and accounting. The word "control" comes from the Medieval Latin ‘contrarotulus’, which means "counter-roll." This was a duplicate ledger used in the Middle Ages to check the accuracy of the primary financial records—a literal act of checking one roll against another.  

For centuries, this was the essence of control: a manual, detective action to verify financial accuracy. The concept evolved with the Industrial Revolution, as owners became separated from the day-to-day management of their companies and needed systems to ensure operations were running correctly. The modern era of control was forged after the massive accounting scandals of the early 2000s, like Enron and WorldCom. These events led to legislation like the Sarbanes-Oxley Act (SOX), which legally mandated that corporate management be held personally responsible for the effectiveness of their internal controls over financial reporting.  

This history is important because it shows that controls have always been about providing assurance that objectives are being met and that records are accurate—a principle that has been directly inherited by the world of information- and cybersecurity.

Defining Controls in GRC

In GRC, controls are the specific safeguards implemented to meet requirements. They can be categorized in several ways:

• Preventive: To prevent an incident from happening (e.g., a firewall).

• Detective: To identify an incident after it has occurred (e.g., log reviews).

• Corrective: To recover from an incident after it has occured (e.g. backups).

• Administrative: Policies, procedures, and training (e.g., a security awareness program).

• Technical: Safeguards implemented in software or hardware (e.g., encryption).

• Physical: Mechanisms that protect physical access (e.g., locks, security guards).

The Real Difference between Requirements and Controls

Let's make this concrete. Consider a common requirement from SOC 2's Trust Services Criteria.

The Requirement (The "What"): SOC 2 Common Criteria 6.1 states that the entity must implement logical access security measures to protect information assets from security events.

This is the high-level objective. It doesn't mention passwords, MFA, or hardware keys. It just says, "protect against unauthorized access."

The Controls (The "How"): An organization can't just "do" CC6.1. It must implement a system of controls to meet this requirement. Here’s how that breaks down, using hardware security keys as an example:

Control 1: Access Control Policy (Administrative - Preventive)

• What it is: A high-level document approved by management.

• What it does: It formally states the rules. For example: "Access to sensitive systems must be granted based on the principle of least privilege and authenticated using multi-factor authentication (MFA)." This policy is the foundation.

Control 2: MFA with Hardware Keys (Technical - Preventive)

• What it is: The technology chosen to enforce the policy.

• What it does: The organization configures its identity provider (like Okta or Azure AD) to require a FIDO2-compliant hardware security key (e.g., a YubiKey) in addition to a password for every login to a critical system. This is a powerful technical control. But the technology alone is not enough.

Control 3: Hardware Key Lifecycle Management (Administrative - Preventive)

• What it is: The documented processes for managing the physical keys. This is where many companies fall short.

• What it does: This control is actually a set of procedures:

  • Issuance Process: When a new employee starts, HR triggers a ticket. IT meets with the employee, verifies their identity against government ID, issues them a new key from a secure inventory, and records the key's serial number in an asset management system tied to that employee's identity.

  • Revocation Process: When an employee leaves, the offboarding checklist includes a step for IT to immediately de-register their key from all systems. The physical key is collected and securely destroyed.  

  • Loss/Theft Process: A procedure for an employee to report a lost key, for IT to immediately revoke it, and for a new one to be issued after identity verification.

Control 4: Quarterly User Access Reviews (Administrative - Detective)

• What it is: A periodic check to catch errors or unauthorized access.

• What it does: Every three months, an automated report is generated showing every user and their access levels to critical systems. This report is sent to the user's manager, who must review and formally approve that the access is still required for their job role. This detective control verifies that the preventive controls are working correctly over time.

As you can see, one high-level requirement spawned a whole ecosystem of interconnected controls—administrative and technological—that work together to achieve the objective of the requirement.

The Bottom Line

The bottom line is simple: Requirements set the objectives; controls are the specific actions you take to get there. A mature GRC program is built on a clear understanding of this dynamic, translating high-level objectives into the real-world policies, processes, and technologies that keep an organization secure and compliant.

Test your Knowledge

Today’s question is from the CISM curriculum:

What is the MAIN reason for implementing multi-factor authentication?

A) To increase user convenience
B) To meet compliance requirements
C) To enhance security
D) To reduce costs

👉 Think you know the answer? Scroll down for the solution!

Answer: The correct answer is C.

A) Multi-factor authentication may actually reduce user convenience.
B) Compliance may require it, but the main reason is to enhance security.
C) Multi-factor authentication provides multiple layers of security.
D) It may actually increase costs due to the need for additional hardware or software.

Here’s what we got for you today:

• CISA's ticking clock, U.S. Congress is racing to revive an expiring law.

• Discover our new ISO 27001 DOCS section, designed as a reference guide for learners and professionals.

GRC Spotlight

CISA's Ticking Clock – Congress Races to Extend Cyber Defense

As the September 30, 2025, deadline nears for the Cybersecurity Information Sharing Act (CISA), experts warn its expiration could weaken defenses by reducing threat intelligence sharing, risking hacker exploitation. The House has advanced a revised bill, Wimwag, extending protections to 2035 with updated threats and privacy safeguards. Senate Chair Rand Paul’s push to prevent alleged censorship adds hurdles, while leaders stress collaboration benefits despite critiques of slow intel delivery, calling for better trust in partnerships.

Dear Subscribers,

We are excited to announce the launch of our brand-new ISO 27001 Docs section at GRC Lab! Now, you can access a wealth of free documentation to kickstart your journey toward ISO 27001 compliance.

Designed for learners, professionals, and organizations alike, this resource hub shall evolve to become your go-to reference for mastering information security management systems.

What’s Inside the ISO 27001 Docs Section?

Our docs cover everything you need to know to get started in the world of Information Security Management Systems. Check out these key areas:

• Information Security Fundamentals: Learn the basics of protecting information, and management systems, all grounded in the CIA triad (Confidentiality, Integrity, Availability).

• Implementation Project: Get step-by-step guidance to roll out ISO 27001 in your organization.

• Annex A: Explore security controls to safeguard your information assets.

• Certification Process: Understand the path to achieving and maintaining ISO 27001 certification.

• Career: Discover professional certifications like Lead Implementer and Lead Auditor, to take your career to the next level.

Why Choose Our Docs?

You can find a ton of information about ISO 27001 online, but it’s often fragmented and time-consuming to piece together. Our new section consolidates everything in one place, saving you effort while delivering clear, actionable insights to simplify your compliance journey.

Check it out

New YouTube Video

Most of our learners prefer video content over static texts. Our latest explanatory video is about the CIA triad, clear, concise and (hopefully) visually appealing. Feel free to have a look and subscribe to our channel.

Test your Knowledge

Today’s question is from the [CISM] curriculum:

When is it MOST appropriate to use a risk avoidance strategy?

A) When the risk is low frequency and low impact
B) When the risk is high frequency but low impact
C) When the risk is low frequency but high impact
D) When the risk is high frequency and high impact

👉 Think you know the answer? Scroll down for the solution!

Answer: The correct answer is D.

A) For low frequency and low impact risks, avoidance might be an unnecessary overreaction.
B) For high frequency but low impact risks, risk acceptance or mitigation might be more suitable.
C) For low frequency but high impact risks, risk transfer might be more appropriate.
D) For high frequency and high impact risks, avoiding the activity causing the risk is often the best course of action to protect the enterprise.

Here’s what we got for you today:

• Revision 5.2.0 of NIST SP 800-53 has added three new controls and enhancements to our beloved control catalogue.

• How to stand out by combining ISO 27001 with sector specific standards.

GRC Spotlight

Last week NIST provided us with another update of NIST SP 800-53. As part of revision 5.2.0, three new controls were added to the control catalogue.

• SA-15 - Logging Syntax

• SI-02(07) - Root Cause Analysis

• SA-24 - Design for Cyber Resiliency

You can find the official summary of changes here.

Hey GRC Lab readers! 👋

Imagine a security framework that works for any organization—big or small, tech or healthcare, startup or enterprise. That’s ISO/IEC 27001, the gold standard for building an Information Security Management System (ISMS).

While the ISO 27001 standard provides a solid backbone for an ISMS, its high-level nature means it cannot address every technical or operational nuance of a specialized industry. This is not a failure of the standard, but a deliberate design choice that allows for its broad applicability. The true power of the ISO 27k series lies in its ability to be extended. To better suit their industry and address unique, high-impact risks, organizations can decide to select additional controls that are not part of Annex A. While this might sound like quite a challenge, rest assured you are not on your own on this.

The following ISO standards function as extensions to the controls of Annex A, and address a variety of different industries and use cases.

• ISO/IEC 27011

• ISO/IEC 27017

• ISO/IEC 27018

• ISO/IEC 27019

Overview of sector specific standards

Here is a brief overview about each of these standards, explaining who they are tailored to and what types of controls are suggested by them.

ISO/IEC 27011: Building a Resilient Telecom Backbone

Description: Telecommunications organizations operate in a unique and critical domain, managing vast volumes of sensitive user data and networks that constitute national infrastructure. While a general ISMS is helpful, it is insufficient to address the specific threats faced by this industry, such as interconnection fraud, SIM card cloning, transmission snooping, and the manipulation of signaling protocols like SS7, SIP, or Diameter. ISO 27011 is a sector-specific standard that adapts and extends the controls from ISO 27002 to match the complex risks and technological requirements of the telecommunications industry. It provides tailored security controls that support the need for network stability, continuous service availability, and the confidentiality and integrity of communications across complex and distributed infrastructures.

Added Controls and Guidance:

• Apply access control policies specific to network elements and subscriber data.

• Secure the signaling systems (e.g., SS7, SIP, or Diameter) from external manipulation.

• Protect physical telecom infrastructure, including towers and switches.

• Implement audit logging and regular event correlation for telecom services.

• Restrict administrative privileges and enforce role-based access to critical systems.

• Ensure resilience of telecom services against denial-of-service and other disruptions.

• Control changes to telecom hardware and firmware, especially in live environments.

• Address security responsibilities prior to, during, and after employment for critical roles.

ISO/IEC 27017: Navigating the Cloud Shared Responsibility Model

Description: The cloud’s “shared responsibility model” is often a source of significant ambiguity, leaving high-impact weaknesses exposed. Generic ISMS frameworks are outpaced by the dynamic, multi-tenant nature of cloud environments and their fragmentation. ISO 27017 was created to clarify this ambiguity, providing cloud-specific security controls and implementation guidance for both cloud service providers (CSPs) and customers, forcing clarity through naming, assignment, and secure accountability. The standard shifts the security focus from a static, periodic model to one that is dynamic and automation-driven, addressing risks in virtual asset management, automated auditability, and lifecycle provisioning.

Added Controls and Guidance:

• A control for the allocation of responsibilities between the cloud service provider (CSP) and the customer.

• A control for the removal or return of assets when a contract is terminated.

• A control for the protection and separation of a customer’s virtual environment.

• A control for virtual machine configuration.

• A control for administrative operations and procedures associated with the cloud environment.

• Guidance on cloud customer monitoring of activity.

• Guidance on virtual and cloud network environment alignment.

ISO/IEC 27018: A Privacy-First Approach for PII in the Cloud

Description: Generic ISO 27001 controls, while strong on information security, are often insufficient for protecting Personally Identifiable Information (PII) in public cloud environments. They fail to address the critical nuances of privacy principles, such as explicit consent management, data minimization, and the legally distinct roles of data controllers and processors. ISO 27018 was developed to close this gap by adding specific, auditable controls for public cloud providers acting as PII processors. The standard transforms data protection from an abstract intention into "daily, granular accountability."

Added Controls and Guidance:

• Consent Management: Dynamic, always trackable, explicit, and logged.

• Processor-Controller Split: Mandatory, with an audit trail that can be cited.

• Data Deletion/Erasure: Technical, monitored, and regular.

• Cross-Vendor Proof: API/event-based and audit-ready.

• Role Assurance: Contractually enforced and mapped.

• Transparency: Mandatory notification to affected partners and clients.

ISO/IEC 27019: Defending the Grid from the Inside Out

Description: The energy utility industry relies on a distinct class of systems known as Operational Technology (OT), including industrial control systems (ICS) like SCADA and Programmable Logic Controllers (PLCs). These systems are uniquely vulnerable due to their physical exposure and distributed nature. A security failure in this domain can lead to a physical event, such as a grid blackout. Traditional IT security frameworks ignore this "civilian blind spot." ISO 27019 provides a specialized playbook for securing OT environments, offering a security standard that makes sector-specific risk visible and actionable.

Added Controls and Guidance:

Implications for External Audits and Certificates

Now the question is what about the certification process? Is it possible to get a real certificate for each of the standards we discussed?

The short answer is, no you can’t. Since codes of practice cannot be certified on their own the certification is always granted to the management system standard, which is ISO 27001. However, your certificate will reflect the successful integration of the other standards in the scope statement.

In summary, you will get an ISO 27001 certificate with a statement referring to the additional standards that have been considered when auditing the ISMS.

My personal opinion: Most companies implement ISO 27001 because their customers require them to. It’s a means to stay in business with them. The truth is, most customers do not know about or require any of the standards we discussed in this edition. So, the effort it would take to add another set of requirements should be well considered. Nevertheless if your objective is to make your organisation more secure, tailoring your controls to the unique circumstances should be a no brainer.

Test your Knowledge

Today’s question is from the CISM curriculum:

What is the primary purpose of a Data Loss Prevention (DLP) system?

A) Intrusion Detection
B) Data Backup
C) Prevent Unauthorized Data Exfiltration
D) Firewall Management

👉 Think you know the answer? Scroll down for the solution!

Answer: The correct answer is C.

A) Intrusion Detection is not the primary purpose of DLP.
B) Data Backup is not the primary purpose of DLP.
C) DLP is primarily used to prevent unauthorized data exfiltration.
D) Firewall Management is not the primary purpose of DLP.

Here’s what we got for you today:

• Learn why and how to combine NIST SP 800-53 with ISO/IEC 27001 to take your GRC program to the next level.

• Be among the first to hear about our upcoming GRC bootcamps.

Why you shouldn’t use Annex A

Ever poured hours into mapping out security controls from ISO 27001's Annex A, only to realize they feel more like vague suggestions than actionable steps? You're not alone, this is a common pitfall that leaves many GRC teams scratching their heads.

But what if I told you Annex A isn't meant to be your control catalogue at all? Let's unpack this misconception and explore why NIST SP 800-53 might be the upgrade your compliance program needs.

The Role of Annex A in ISO 27001

Annex A in ISO 27001 is frequently misunderstood as a complete control catalog. In reality, it’s more of a checklist to ensure that no important controls have been overlocked or ommitted.

What It Is: Annex A contains 93 information security reference controls across 4 themes, that shall be compared against the controls that have been determined as necessary to treat identified risks.

What It Isn’t: It’s not a detailed control catalogue, describing what must be done.
Let’s look at an example to better understand the difference between the reference controls of Annex A and actual security controls. What about Control A.8.5 Secure Authentication.

As you can tell the example control from Annex A is broad and lacks specifics, such as which technologies to use or how to configure them. It’s merely a description of a desired state but doesn’t go into the specifics. The idea is the following: First, the standard wants you to determine controls that are able to treat your identified risks. Then you must compare them with those listed in Annex A. So, if your organization is facilitating hardware security keys, then obviously those are a form of secure authentication technologies. Therefore control A.8.5 would be necessary, or often expressed as, applicable.

So without actual controls, there is no way to implement A.8.5. What you need are real specific, risk-based controls. Here are practical examples:

• Hardware Security Keys: Deploy devices like YubiKey for phishing-resistant authentication, requiring physical interaction for access.

• MFA Authenticator Apps: Use apps like Authy for time-based one-time passwords (TOTPs), enforced across all accounts and integrated with identity providers.

• Single Sign-On (SSO): Implement SAML-based SSO with providers like Okta, including session timeouts and IP-based restrictions.

• Biometric Authentication: Add fingerprint or facial recognition for sensitive systems, paired with liveness detection to prevent spoofing.

• Certificate-Based Authentication: Use digital certificates for machine-to-machine access, with automated revocation for expired credentials.

These turn A.8.5 into something tangible, but Annex A doesn’t provide this level of detail. That’s where NIST SP 800-53, or ISO/IEC 27002 comes in.

Why NIST SP 800-53 is a great Companion

NIST SP 800-53 is a comprehensive control catalog with over 1,000 controls across 20 families, designed for federal agencies but adaptable for any organization. Unlike Annex A, it provides actionable, detailed guidance.

• Granular Structure: Controls are organized into families like Access Control (AC) and Identification and Authentication (IA), with baselines (low, moderate, high) and enhancements for customization.

• Detailed Instructions: For authentication, IA-2 mandates MFA for privileged users, while AC-7 specifies lockout thresholds (e.g., 5 failed attempts in 15 minutes).

• ISO Compatibility: NIST controls can map to Annex A, ensuring compliance while strengthening security.

• Future-Proofing: Covers modern threats like zero-trust architectures and supply chain risks, with regular updates.

NIST Control Families

• Access Control (AC)

• Awareness and Training (AT)

• Audit and Accountability (AU)

• Assessment, Authorization, and Monitoring (CA)

• Configuration Management (CM)

• Contingency Planning (CP)

• Identification and Authentication (IA)

• Incident Response (IR)

• Maintenance (MA)

• Media Protection (MP)

• Physical and Environmental Protection (PE)

• Planning (PL)

• Program Management (PM)

• Personnel Security (PS)

• PII Processing and Transparency (PT)

• Risk Assessment (RA)

• System and Services Acquisition (SA)

• System and Communications Protection (SC)

• System and Information Integrity (SI)

• Supply Chain Risk Management (SR)

You can find all controls right here: CSRC

Transitioning to NIST: A Step-by-Step Guide

Here’s how to enhance your ISMS with NIST SP 800-53:

1. Evaluate Current Controls: Review your Statement of Applicability (SoA) to identify weak Annex A implementations. Use a gap analysis to assess maturity (e.g., is A.8.5 just a policy or fully enforced?).

2. Map to NIST: Align Annex A objectives with NIST controls using NIST’s mapping tools or a custom spreadsheet. Pair A.8.5 with for example IA-2 (MFA) and IA-5 (authenticator management).

3. Customize Controls: Select NIST controls based on your risk profile. For example, define standards for hardware keys or integrate SSO with your directory service.

4. Implement in Phases: Start with pilot deployments (e.g., MFA for admins), then scale enterprise-wide. Update your SoA to reflect NIST enhancements.

5. Test and Validate: Conduct penetration tests or audits to verify controls. Monitor metrics like failed logins and adjust as needed (e.g., add training from NIST’s AT family).

6. Maintain and Update: Review annually to incorporate NIST updates, ensuring alignment with new threats.

Key Takeaways

Here is what to remember from this article:

• Annex A is a reference for comparison, not a detailed implementation guide.

• NIST SP 800-53 provides over 1,000 actionable controls, making it ideal for mature security programs.

• Combining NIST SP 800-53 is possible and explicitly allowed by ISO/IEC 27001.

Test your Knowledge

Today’s question is from the CGEIT curriculum:

What is the MAIN benefit of aligning IT performance metrics with business performance metrics?

A) Easier tracking of IT performance
B) Better decision-making for IT investments
C) Increased IT operational efficiency
D) Higher IT team morale

👉 Think you know the answer? Scroll down for the solution!

Answer: The correct answer is B.

A) While tracking may become easier, it's not the main benefit of alignment.
B) Aligning IT metrics with business metrics ensures that IT investments are directly contributing to business goals, facilitating better decision-making.
C) Operational efficiency is important but is a secondary benefit of such alignment.
D) Team morale is important but not the primary reason for aligning IT and business metrics.

Here’s what we got for you today:

• Discover how the NIST Cybersecurity and Privacy Reference Tool is changing how GRC professionals interact with authoritative resources.

• Don’t miss our latest YouTube video, “From Threats to Controls”.

Ever found yourself buried in a 200-page NIST PDF, Ctrl+F-ing your way through controls and guidelines, only to lose track halfway?

If that's your daily grind as a GRC practitioner, it's time for an upgrade. Enter NIST's Cybersecurity and Privacy Reference Tool (CPRT)—a game-changer that's making static documents feel like ancient history.

What is the CPRT?

The CPRT, hosted by NIST's Computer Security Resource Center (CSRC), is an online platform that centralizes and digitizes key cybersecurity and privacy resources. Think of it as a smart library for NIST's flagship publications, like the Cybersecurity Framework (CSF) 2.0, SP 800-53 (Security and Privacy Controls), and SP 800-171 (Protecting Controlled Unclassified Information). Instead of downloading hefty PDFs, you get interactive access to reference data—controls, guidelines, and frameworks—in a structured, user-friendly format.

Launched to modernize how we interact with these resources, the CPRT turns complex docs into searchable, exportable datasets that make their content more accessible and easier to digest.

How CPRT Beats Traditional PDF Reading

Remember the frustration of cross-referencing multiple PDFs during a compliance audit? CPRT flips the script with features designed for real-world use:

• Browsing Made Easy: Navigate through catalogs of publications like a digital bookshelf. Drill down into specific controls or sections without opening a single file.

• Powerful Search: Use keywords to pinpoint exact references across documents. For example, search "data encryption" and get hits from CSF, SP 800-53, and more—in seconds.

• Compare and Export: Side-by-side comparisons of controls from different frameworks? Check. Export data in machine-readable formats like CSV or JSON for integration into your GRC tools.

Real-World Wins for GRC Practitioners

Imagine ensuring your organization complies with NIST SP 800-53's Media Protection controls for a system handling sensitive data. Traditionally, you'd juggle three PDFs: SP 800-53 for the control details, SP 800-53B for the control baselines (Low, Moderate, High), and SP 800-53A for assessment procedures. Tedious and error-prone.

With CPRT, it's really a breeze:

Navigate to the SP 800-53 catalog and select the "Media Protection" (MP) family from the 20 control families.

Click on MP-06 (Media Sanitization) to view its full details in one place.

See the control's requirements (from SP 800-53), its baseline assignments (from SP 800-53B, e.g., included in Moderate and High baselines), and assessment procedures (from SP 800-53A) seamlessly combined.

This unified view saves hours of cross-referencing. For example, MP-06 requires sanitizing media before disposal or reuse, and CPRT shows you the exact methods (e.g., clear, purge, destroy), baseline applicability, and how to assess compliance—all in one interface. Early adopters report cutting research time by half, letting them focus on high-impact areas like emerging threats.

Ready to level up your GRC game? Check out the CPRT and explore a new way of working with their resources.

Cybersecurity and Privacy Reference Tool | CSRC

Our latest Video on YouTube

Have you ever wondered how threats, vulnerabilities and controls are related? If so, then our latest YouTube might have the answers to your questions. ↓

Test your Knowledge

Today’s question is from the CISM curriculum:

Which of the following metrics is MOST useful in evaluating the effectiveness of a security awareness program?

A) Number of training sessions conducted.
B) Employee feedback on training content.
C) Reduction in security incidents post-training.
D) Attendance rate for training sessions.

👉 Think you know the answer? Scroll down for the solution!

Answer: The correct answer is C.

A) The number of sessions does not indicate effectiveness.
B) Feedback is useful but not a direct measure of effectiveness.
C) A reduction in security incidents directly indicates the program's effectiveness.
D) Attendance rate shows interest but not effectiveness.