DEV Community: CSFaaS

Back to Basics: Risk Appetite & Risk Tolerance

CSFaaS — Sun, 20 Sep 2026 14:29:37 +0000

Risk appetite and risk tolerance are core concepts in risk management and GRC, helping organisations connect strategic intent with risk decision-making. And sometimes, going back to basics is exactly what we need.

A simple distinction:

Risk appetite sets the overall direction.
Risk tolerance makes that direction usable for specific decisions.

In this article, I look at where these concepts come from, how COSO, ISO and NIST frame them, and how they connect governance with practical risk decisions.

The key question is not simply whether an organisation has a risk appetite statement.

It is whether that statement can actually guide risk acceptance, treatment, exceptions, escalation and reporting.

Where do these concepts come from?

The modern concepts of risk appetite and risk tolerance developed through financial risk management, corporate governance and Enterprise Risk Management, before being incorporated into international risk management standards.

Turnbull Guidance (1999): helped frame the underlying governance question by asking boards to consider the extent and categories of risk acceptable for the company to bear.
COSO ERM (2004): formalised the distinction more explicitly. Risk appetite was positioned at the broader enterprise level, while risk tolerance described the acceptable variation relative to achieving specific objectives.
COSO ERM (2017): further integrated risk appetite with strategy and performance. Subsequent COSO guidance describes tolerance in terms of acceptable variation in performance relative to objectives, reinforcing the link between risk-taking, strategy and execution.
ISO Guide 73:2009: incorporated both risk appetite and risk tolerance into the ISO risk management vocabulary. Its successor, ISO 31073:2022, retains both concepts, defining risk appetite as the amount and type of risk an organisation is willing to pursue or retain, and risk tolerance as the organisation's or an interested party's readiness to bear residual risk in order to achieve its objectives.
FSB Principles for an Effective Risk Appetite Framework (2013): following the global financial crisis, connected risk capacity, appetite, limits and risk profile with strategy and board oversight.

The terminology differs across frameworks.

COSO emphasises acceptable variation around objectives and performance, while ISO expresses tolerance in terms of readiness to bear residual risk.

Despite those differences, both seek to translate an organisation's attitude toward risk into guidance for decision-making.

One picture, two concepts

Illustrative relationship between expected performance, risk appetite, risk tolerance and the broader risk universe.

Source NIST SP 800-161 Rev. 1 Update 1, Figure 16, printed page 268 (PDF page 282).

The diagram places expected performance within a broader risk universe, ranging from the best to the worst possible outcomes.

Risk appetite represents the range within which the organisation intends to operate.

Risk tolerance may establish wider boundaries, providing some flexibility around that appetite.

Between the two lies the review zone: a departure from appetite that remains within tolerance, but warrants attention and review.

In simple terms:

Appetite provides the direction.

Tolerance establishes the boundaries around that direction.

From governance to decisions

A simple way to view the relationship is:

Objectives → Risk Appetite → Risk Tolerance → Risk Decisions

Risk appetite provides overarching guidance about the risks an organisation is prepared to take in pursuit of its objectives.

Risk tolerance translates that direction into more specific boundaries.

Together, they help communicate risk expectations, support consistent decision-making, and determine when a risk may require treatment, acceptance, exception or escalation.

Those boundaries should remain aligned with senior leadership direction and take into account applicable legal, regulatory and contractual requirements.

What it looks like in practice

Illustrative examples from NIST SP 800-221, Table 3.

Take the government agency example.

The appetite establishes the direction: mission-critical systems should be protected from known ICT vulnerabilities.

The corresponding tolerance makes that direction actionable by defining a 14-day remediation boundary for critical vulnerabilities on systems designated as mission-critical.

The academic institution example shows that tolerance can also be conditional.

Some loss of student devices is expected and accepted, while there is no appetite for the loss of sensitive institutional information. The tolerance therefore applies only if sensitive information is prohibited from being stored on those devices.

The thresholds themselves are illustrative, not universal.

A 14-day remediation period, a four-hour outage or a particular loss threshold should not become an organisational tolerance simply because it appears in guidance.

What matters is that the tolerance is specific enough to make the broader appetite usable in governance and decision-making.

In a GRC context

Risk appetite and tolerance should not exist as isolated statements.

They should inform the organisation's broader GRC mechanisms, including risk assessment and acceptance criteria, policies, controls, exceptions, remediation, escalation and reporting.

This connection is explicit in NIST CSF 2.0, where GV.RM-02 expects risk appetite and risk tolerance statements to be established, communicated and maintained.

ISO/IEC 27001 also requires organisations to establish information security risk acceptance criteria. It does not define risk appetite or tolerance itself, but those concepts can help inform how such criteria are established.

This is ultimately what makes appetite and tolerance useful: they connect strategic risk direction with the way risk is governed across the organisation.

Risk appetite sets the direction.

Risk tolerance makes that direction usable for governance and decision-making.

Sources

Building a More Complete GRC Platform — The Latest CSFaaS Updates

CSFaaS — Sun, 23 Aug 2026 20:31:16 +0000

While many are taking a summer break, we have been doing what we love: building for you.

Since late July, 55 issues have moved to Done across CSFaaS.

Some introduced new capabilities. Others fixed edge cases, tightened workflows, improved auditability, improved usability, or hardened the platform underneath.

Taken together, they tell an important story: CSFaaS is becoming a more mature, reliable and operational GRC platform, release after release.

Here is a snapshot of what has kept the team busy over the past few weeks.

AI prompts and automation

One of the most important additions is the new ability to create, store and manage reusable AI prompts directly in CSFaaS.

These prompts are designed to help teams automate and standardize recurring GRC activities.

They can be used, for example, to:

review controls and evidence;
document or assess risks;
check framework implementation status;
generate summaries;
produce recommendations;
support audit preparation;
standardize recurring analysis and review activities.

Instead of rewriting the same instructions every time, teams can now turn their own methodologies and best practices into reusable AI workflows.

This is also a natural extension of CSFaaS' MCP architecture.

The objective is not to place an AI chatbot next to the platform.

It is to make AI available throughout the GRC operating model, connected to the information already managed inside CSFaaS: frameworks, controls, risks, policies, evidence, audits and related workflows.

AI is no longer a separate assistant sitting next to the GRC platform. It becomes part of the way the GRC platform operates.

MCP hardening

The MCP layer has also received significant attention over the past few weeks.

Several issues were fixed around write operations, usage reliability and restricted permissions. We also improved the way PDF evidence can be read and added protections to prevent internal application codes from being unintentionally modified.

These may sound like technical details, but they become critical when AI agents are allowed to interact directly with governance data.

Launching an MCP server is relatively easy to announce.

Making it reliable enough for real operational use is a different challenge.

A failed write is inconvenient.

An incorrect write can affect traceability.

An accidentally modified identifier can affect data integrity.

As AI becomes more deeply integrated into GRC processes, the reliability of the MCP layer increasingly becomes part of the reliability of the platform itself.

CyFun integration

CyFun has been another major area of work.

Seven workstreams were completed around the CyberFundamentals Framework (CyFun®), including:

support for both Documentation maturity and Implementation maturity;
a dedicated summary page;
import from the official self-assessment workbook;
export back to the official workbook format;
support for Key Measures and Management Aspects;
version-handling improvements;
broader integration into the CSFaaS framework architecture.

The important point is not simply that CSFaaS supports another framework.

The objective is to integrate CyFun into the same underlying GRC model already used for other standards and regulations.

That means avoiding unnecessary duplication.

Controls, risks, evidence, policies and implementation work should be reusable wherever possible across multiple frameworks.

For us, adding another framework should not mean adding another compliance silo.

Risk and Demand workflows

A substantial amount of work also went into improving risk and demand workflows.

Recent changes include the ability to create Risk Demands on behalf of another user, cumulative edit permissions for requests and remediation plans, fixes around response rounds, improvements following the Request Information step, and locking certain review parameters once a risk response has been submitted.

These are the kinds of changes that rarely make release headlines.

But they determine whether a workflow remains reliable once multiple people, roles and review cycles are involved.

A workflow that works during a demonstration is one thing.

A workflow that remains consistent when responsibilities change, information is incomplete, reviews are reopened and multiple stakeholders are involved is another.

That is where product maturity starts to show.

Auditability and framework usability

We also continued improving the experience around frameworks, controls and audits.

Recent changes include the addition of an Audit Conclusion tab to audit framework elements, clearer Finding Register and Actions Register views, support for a Partially implemented applicability status, improved control progression behaviour and several fixes affecting maturity and target maturity displays.

We also corrected smaller usability issues, such as evidence names not appearing correctly in drawers and visual inconsistencies in applicability statuses.

Individually, these are small changes.

During a real audit or assessment, however, small inconsistencies quickly become visible.

A GRC platform should reduce ambiguity, not create it.

The more the platform is used as a system of record, the more important this level of detail becomes.

Permissions and activity visibility

Permissions and traceability also continued to evolve.

We extended role-based access in several areas, improved activity log access configuration and refined permissions around requests and remediation plans.

These changes are important because GRC platforms are collaborative by nature.

Different people need different levels of access, but the platform still has to preserve accountability, ownership and traceability.

The challenge is not simply to restrict access.

It is to provide enough flexibility for organisations without weakening governance.

Platform, scale and monitoring

Some of the work happened deeper in the architecture.

This included event-plane storage improvements designed for scale, as well as export capabilities for MCP and API activity monitoring.

These changes are less visible in the user interface, but they matter as the platform grows.

Operational monitoring, activity traceability and scalable storage are not optional once a GRC platform becomes part of day-to-day security and compliance operations.

Product experience

We also continued refining the broader CSFaaS experience.

That included dashboard fixes, navigation improvements, contextual help for Risk Profiling, terminology improvements, framework display refinements and changes to how certain views behave.

Again, none of these improvements is revolutionary by itself.

But users do not experience a product as a list of features.

They experience the accumulation of hundreds of interactions.

Every unnecessary click, unclear label, broken navigation path or inconsistent result creates friction.

Removing that friction is part of building the product.

Education

The last few weeks were not limited to the application itself.

We launched the new CSFaaS Education Program page.

The Education Program is particularly important to us.

Our goal is to make professional GRC tooling more accessible to universities, schools and training programs, so that students can work with the same concepts and workflows they will encounter in real organisations.

Website

We also launched a fully redesigned CSFaaS homepage, with clearer positioning, updated messaging and a better overview of the platform and its capabilities.

We would genuinely like your feedback.

Take a look at the new homepage and tell us what you think — what is clear, what is missing, and what we could improve.

The accumulation matters

There is no single feature that defines these four weeks.

And that is probably the most interesting part.

A mature GRC platform is not built only through large launches.

It is built through the accumulation of improvements across workflows, permissions, auditability, integrations, reliability, AI, infrastructure and user experience.

The small things matter because GRC itself is built on consistency.

When someone runs an audit, reviews a risk, checks evidence, assigns responsibility, maps a framework or lets an AI agent interact with governance data, the platform has to behave predictably.

That is what the last few weeks have been about.

55 issues shipped since late July.

And there is more coming in the next few days, with several major new capabilities that will take CSFaaS another step closer to becoming one of the most complete GRC platforms on the market.

Welcome to the leading edge of GRC.

AI Content Watermarking: Claude Starts Marking AI-Generated Content

CSFaaS — Fri, 21 Aug 2026 11:03:01 +0000

Anthropic has announced plans to mark content generated or processed by Claude as part of its commitments under the EU AI Act and the Code of Practice on Transparency of AI-Generated Content.

For new Claude models launched in the EU on or after August 2, 2026, Anthropic says marking will be supported from launch.

The approach relies on two complementary mechanisms: embedded watermarks in text and signed provenance metadata for files.

An Invisible Watermark Embedded in Text

This is perhaps the most interesting part of the announcement.

When a supported Claude model generates text, Anthropic says it will embed an imperceptible watermark directly into the text.

This is not simply a visible “Generated by AI” label. According to Anthropic, the watermark travels with the text when it is copied and pasted and may remain detectable after some editing.

How is that possible?

Anthropic has not yet published the technical details of its implementation and says further technical documentation will follow.

One possible approach to this type of watermarking is to introduce a statistical signal during text generation. A model can favor certain token choices or formulations among several possible alternatives, creating a statistical pattern that can later be detected across a sufficiently large sample of text.

Such an approach would explain why a watermark could survive limited editing while becoming increasingly difficult to detect after substantial rewriting.

Copying the Text May Not Remove the Mark

This has an important consequence.

A simple copy and paste preserves the text and may therefore preserve the watermark.

Limited modifications may also leave enough of the signal intact for detection.

However, Anthropic explicitly acknowledges several limitations. Heavy editing, paraphrasing, translation or combining the content with other text may make the watermark undetectable.

Very short passages may also contain too little information to provide a reliable signal.

A text watermark should therefore be considered a provenance signal rather than absolute proof of authorship.

C2PA Provenance Metadata for Files

For supported files, Anthropic is taking a different approach.

Claude will attach signed provenance metadata to supported file types such as SVG, PNG and JPEG.

This metadata follows C2PA (Coalition for Content Provenance and Authenticity), an open industry standard designed to provide verifiable information about the origin and history of digital content.

When signed provenance metadata is present, it can indicate that a file was processed by Claude and help detect whether it has subsequently been altered.

This approach is particularly interesting for images and other digital assets because it moves the discussion beyond simple AI detection toward broader content traceability and provenance.

It also has limitations. Metadata can disappear when files are converted, re-saved, screenshotted or processed by systems that do not preserve it.

“Processed by Claude” Does Not Mean “Created by Claude”

This is probably the most important distinction in Anthropic’s announcement.

Detecting a Claude mark does not necessarily mean that Claude originally created the content.

Consider a simple example.

A person writes an entire article and then asks Claude:

“Correct the spelling and improve the style slightly.”

The resulting text may carry a Claude mark even though the ideas and original content came from a human author.

The same applies to translation, summarization, proofreading or file conversion.

It would therefore be incorrect to interpret a detected mark automatically as:

“This content was written by AI.”

A more accurate conclusion would be:

“This content may have been processed by Claude.”

That distinction matters.

No Watermark Does Not Mean “Human”

The opposite is equally important.

The absence of a detectable watermark does not prove that content was created by a human.

Anthropic identifies several situations where Claude-generated or Claude-processed content may no longer carry a detectable mark:

it was generated by a model that did not yet support marking;
the text was heavily edited or paraphrased;
it was translated;
it was combined with other content;
the passage is too short;
file metadata was removed;
the platform, feature or file format did not support a particular marking mechanism.

This highlights a fundamental limitation of AI-content detection.

These mechanisms can provide signals, but those signals should not be treated as definitive proof.

From AI Detection to Content Provenance

This development is particularly interesting because it may gradually change the question we ask about digital content.

Today, the common question is:

“Was this text or image created by AI?”

But that distinction is becoming increasingly difficult to establish — and increasingly less meaningful.

Content can be:

written by a human and corrected by AI;
generated by AI and extensively rewritten by a human;
translated by AI;
summarized by AI;
assembled from multiple human and AI-generated sources;
or processed successively by several AI systems.

A simple Human vs. AI classification quickly reaches its limits.

We are therefore gradually moving from:

“Is this AI?”

to:

“What is the provenance of this content?”

That is a much more meaningful question.

A New Dimension of AI Governance

For organizations, this development goes far beyond identifying AI-written articles on the Internet.

As generative AI becomes integrated into business processes, organizations will increasingly need to understand — and in some cases demonstrate:

which AI systems were used;
which content was generated or transformed;
where human intervention occurred;
what modifications were made;
what provenance evidence is available.

In other words, traceability is becoming an important component of AI governance.

This is a familiar principle in cybersecurity and GRC. Organizations cannot rely solely on statements that a process is controlled. They increasingly need evidence showing how processes operate and, where necessary, the ability to trace what happened.

Technologies such as watermarking and C2PA can contribute to that traceability, although they cannot provide the entire solution on their own.

An Important Step, but Not a Perfect Solution

Anthropic’s initiative represents an interesting step toward greater transparency around AI-generated content.

But its limitations are just as important as the technology itself.

A watermark can become undetectable.

Metadata can be removed.

Marked content may originally have been created by a human.

And unmarked content may still have been generated by AI.

The real objective may therefore not be to build a universal detector capable of answering “human or AI?” with certainty.

Instead, the challenge is to develop an ecosystem of provenance, traceability and governance for digital content.

As the EU AI Act progressively takes effect, this topic is likely to become increasingly important — both for AI model providers and for the organizations using these systems.

AI content watermarking: a real step forward for transparency, or a measure that will ultimately be easy to circumvent?