Rethinking Risk: How Cybersecurity and Compliance Teams Can Thrive in Decentralized Decision-Making

By Denis Ontiveros
“Architecture is about conversations. So is risk.”

In today’s fast-paced technology environments, risk and control functions are being pulled in two directions.

On the one hand, the speed of delivery demands that decisions be made quickly, close to the context, and by the people doing the work. On the other, security, privacy, and compliance obligations are more intense than ever—and rightly so. A single misstep can have regulatory, reputational, and systemic consequences.

Traditionally, the way to resolve this tension has been to centralize control. Introduce governance boards, review gates, approval workflows. But these mechanisms were designed for slower-moving systems—and they struggle in today’s fluid, distributed environments.

A new approach is emerging. One that blends responsibility and speed. One that fosters inclusion without control paralysis.

This is the Advice Process—and it's increasingly relevant not only to architecture and engineering, but to cybersecurity, privacy, and compliance as well.

The Advice Process: A Decentralized Decision Model for Fast-Moving Teams

The Advice Process is simple on the surface, yet deeply transformative in practice. It allows anyone to take a decision, as long as they:

• Seek input from those affected by the decision
• Consult with those who have expertise in the relevant area

Once that advice is sought, listened to, and understood, the decision-maker is free to act. The process doesn’t require consensus or approval. It only requires inclusion and accountability.

This subtle shift in dynamic—from control to counsel—allows for speed without recklessness, and decentralization without chaos.

It is a trust-based social contract in which roles are fluid. Today, you may be the decision-maker. Tomorrow, you’re the expert offering advice. The next day, you’re the impacted stakeholder whose experience helps shape the path forward.

A Kinship with the Consent Process

If this sounds familiar to you, it may be because the Advice Process shares philosophical ground with the Consent Process often used in participatory governance and organizational design.

Both models are built on similar premises:

• Decisions should be made as close to the context as possible
• Speed matters—but so does the wisdom of the crowd
• Trust is a design principle, not a byproduct
• Inclusion doesn’t require consensus—just transparency, intent, and responsibility

While each process has its nuances and is rooted in different traditions, they both respond to the same challenge: how can we scale decision-making without scaling bureaucracy?

Rather than compare the two, it’s more helpful to view them as parallel evolutions in how we coordinate, govern, and make change—especially in domains like cybersecurity and compliance, where authority has historically been centralized by necessity.

Why This Matters for Cybersecurity and Compliance Teams

Cyber and compliance functions are used to being gatekeepers. That role made sense in a world of monolithic systems, waterfall projects, and quarterly releases.

But in today’s world—continuous delivery, ephemeral infrastructure, feature flags, and decentralized teams—the gate is often too late.

Yet the obligations remain. We still need to:

• Protect sensitive data
• Maintain audit trails
• Prove compliance to regulators
• Reduce systemic risk

So how do we fulfill these responsibilities without blocking the teams trying to move fast?

By stepping into the Advice Process—not as owners of decisions, but as contributors of essential insight.

A Story: Security as Guide, Not Gate

Let’s make this real.

Imagine a product team wants to switch from their legacy API gateway to a new cloud-native option. It promises faster performance and better routing flexibility. They’re ready to experiment.

In the traditional model, this might trigger a security review request. The team would fill in a form, attach an architecture diagram, and wait. Two weeks later, they receive a spreadsheet of risks and control requirements.

Everyone’s frustrated. Security feels unheard. The team feels blocked. Leadership wonders why innovation is so slow.

Now imagine the same situation under the Advice Process.

• The team shares their intent early: “We’re looking at API Gateway X.”
• They reach out to the security team: “Any concerns we should be aware of?”
• A security architect joins a call and says:

“We’ve used Gateway X before. Great performance, but it doesn’t enforce mutual TLS by default—make sure you configure that. Also, their audit logs don’t redact headers, so wrap sensitive data before it’s logged. Want me to send you a template config?”

That’s it.

Advice. Not control.

The team moves forward—better informed, safer, and without delay. And the security team didn’t have to chase, block, or escalate. They were included early, respected for their expertise, and free to move on to the next engagement.

Advice Is Not Opinion. And It’s Not Approval.

One of the common misunderstandings about the Advice Process is that it’s vague or informal. In fact, it’s the opposite. It demands clarity—especially in the distinction between advice and opinion.

An opinion is:

“I don’t like that vendor.”

Advice is:

“That vendor failed us last year because of a logging bug they took three weeks to fix. If you use them, log early and test your fallback paths.”

Advice includes the “why”—the reasoning, context, and experience behind the suggestion. It’s not about authority. It’s about contribution.

Equally important: offering advice does not make you accountable. Taking a decision does.

This is often the hardest shift for compliance and security teams. It requires letting go of the idea that control = protection. Instead, it embraces the idea that shared context = safer decisions.

So What Changes for Risk and Compliance Roles?

Moving from a control model to an advice model doesn’t dilute responsibility—it redistributes it. Here's how the dynamic shifts:

Before:

• Risk teams issue controls and expect compliance
• Product teams seek approval late (or not at all)
• Both sides feel frustration and friction

After:

• Risk teams offer foresight early
• Product teams seek advice proactively
• Decisions move faster, and risk is more visible

To support this, security and compliance roles must become more embedded in the flow of work. They become:

• Partners in decisions, not approvers of them
• Curators of insight, not enforcers of policy
• Guides, not guards

Making the Advice Process Real

The Advice Process doesn’t work by decree. It works by participation. So how can risk and security teams start showing up differently?

Here are a few practical ways:

Start small, but early:

• Join architecture spikes, backlog grooming, or ideation sessions
• Ask teams: “What decisions are you considering? Can I help think them through?”

Write advice down:

• Maintain “Frequently Offered Advice” pages or internal blog posts
• Share lessons from incidents, audits, and near misses

Be clear about your role:

• Say explicitly: “This is advice, not an approval. You own the decision.”

Ask questions instead of making rules:

• “What data will this new service process?”
• “How will you detect anomalous behavior?”
• “Have you considered how this logs PII?”

Encourage lightweight documentation:

• Ask teams to write an ADR (Architecture Decision Record) capturing context, options, and consequences
• Use those records to trace risk decisions, not to control them

Celebrate transparency:

• When a team makes a good decision that includes risk thinking, acknowledge it
• Let leadership know that the right conversations are happening without escalation

Trust Is the Real Control

Both the Advice Process and the Consent Process work because they assume one thing:

That people, when informed and supported, will act responsibly.

This trust isn’t naive. It’s strategic.

When you design for trust—instead of control—you unlock speed, autonomy, and collective accountability.
And in doing so, you make your organization more secure, not less.

The truth is: no central risk function can scale to match modern delivery.
But a trusted network of decision-makers, advisors, and impacted stakeholders can.

Final Thought: Offer the Advice You’d Want to Receive

As someone in a cyber or compliance role, your goal isn’t just to enforce the rules. It’s to help the organization make better decisions.

That means making yourself visible, helpful, and available. It means sharing your experience, your reasoning, your stories. And it means being okay with someone taking a different path—because they listened to you first.

The Advice Process is not about giving up control.
It’s about placing trust in the system, the people, and the relationships we build together.

So next time you see a decision forming on the horizon, don’t reach for the rulebook.
Start a conversation. Offer your advice.

That’s how you build safer systems at scale. One trusted decision at a time.

Want to explore more ways to embed trust into your delivery process? Follow along at VivingIT Blog.