DEV Community: Massimiliano B.

From Source Control to Supplier Control: Building TPRM Through a Developer Lens

Massimiliano B. — Sat, 27 Jun 2026 11:15:25 +0000

If you're coming from engineering like I was, Third-Party Risk Management feels weirdly... analog at first. No version control, no CI/CD pipelines, no unit tests for vendor compliance. Just spreadsheets, PDFs, and hope.

But here's the thing: after debugging race conditions and production outages, vendor management starts looking familiar. You're dealing with dependencies again—just ones that come with legal contracts instead of package.json files.

The TPRM Workflow (Programmer Edition)

Phase 1: Dependency Scanning = Discovery

In code, npm audit finds vulnerable packages. In enterprises? Procurement databases plus IT asset inventories.

Two problems emerged in my initial review:

Shadow procurement: Teams buying SaaS without telling anyone
Orphaned integrations: APIs still active after projects sunset

The fix wasn't policy—it was visibility. Start mapping suppliers to applications, then application to data classification. If you don't know what data a vendor can touch, you can't assess their risk level properly.

Phase 2: Risk Grading = Severity Labels

I mapped tiers to something developers get intuitively: severity levels.

Tier	Equivalent	Criteria	Response Time Target
1	Critical	Direct env access / PII / Mission-critical	48 hours
2	High	Non-sensitive business data	2 weeks
3	Low	Everything else	Quarterly check-in

Why this matters: triage discipline. Engineers don't treat INFO alerts like SEV-1 outages. Neither should you treat a catering vendor the same as your primary cloud provider.

Phase 3: Questionnaire Design = Interface Contracts

This is where most TPRM implementations fail. Generic questions return generic answers. Here's what shifted my thinking:

Instead of "Do you encrypt data?", ask:

What encryption algorithm and key length?
At-rest vs. in-transit coverage %?
Who manages keys (you or us)?

It's the difference between a boolean API response and structured JSON payloads. You need machine-readable evidence, not marketing copy.

Map questions to frameworks, yes—but frame them around where the vendor lives and operates. SOC 2 for US companies, ISO 27001 for global, GDPR-specific clauses for EU data handlers.

Phase 4: Evidence Validation = Pen Testing Vendors

Anyone can claim PCI-DSS compliance. Not everyone shows the attestation letter dated within last 90 days. Or proves MFA enforcement across admin accounts. Build evidence expectations upfront so vendors self-report correctly before the first email ping-pong cycle.

What gets verified:

Audit reports (current edition)
Certifications (active status)
Insurance coverage limits
Incident response playbooks (actual documents, not summaries)

When responses lag or seem incomplete, loop your security engineers early. Their threat modeling skills surface risks HR/legal miss entirely.

Phase 5: Remediation Planning = Post-Mortems

Every gap identified creates a ticket - with two assignees (vendor owner AND internal stakeholder). Track timelines. Follow escalations. Close loops publicly. Treat this like incident response documentation, because effectively, a breach via vendor IS an incident you didn't trigger internally.

Where Automation Fits (Because It Does)

Coming from development, I kept spotting redundancy patterns:

Manual discovery → Integrate Procurement + IAM logs daily

Repeated assessments → Template repositories per framework

Evidence chasing → Automated reminder workflows with SLA clocks

Risk scoring → Weighted algorithms based on data sensitivity × exposure vector

Tools exist, sure—but custom solutions beat bloated suites if your org size fits. Think Python scripts querying Google Workspace inventory, pulling vendor contacts via Procurement API, outputting CSV risk matrices ready for leadership decks.

Final Thoughts

Security careers don't always look linear. Some of the best vulnerability hunters started running sales ops. Best pentesters came from customer support desks. Understanding how organizations break—from inside product teams AND procurement processes—makes you dangerous to attackers.

If you're making the jump from engineering to GRC: bring that builder mindset. Automate where others accept friction. Challenge assumptions when "we've always done it this way" meets actual risk metrics. Document everything because institutional memory expires faster than session tokens.

Welcome to the other side of the stack. We could use more of your brains.

From Code to Governance: A Developer's Honest Take on Detection & Incident Response

Massimiliano B. — Fri, 26 Jun 2026 11:48:57 +0000

Introduction

I spent years writing code. Then I sold things. Now I'm pivoting to GRC (Governance, Risk, and Compliance) in cybersecurity. Here's what I learned about Detection and Incident Response that most people don't talk about.

The Reality Most Miss

Detection isn't just logs and alerts.

Most developer documentation treats detection as "set up your SIEM and you're done." That's wrong. Real detection requires understanding three layers:

Technical signals (what your tools see)
Behavioral patterns (what normal looks like for YOUR environment)
Business context (why something matters beyond the alert)

You can have the best log aggregation in the world. If you don't understand which assets actually matter to your business, you're drowning in noise.

Incident Response: The Uncomfortable Truth

When I was a programmer, I thought IR was about containment and fixing the bug. In GRC terms, it's messier:

Technical View	GRC Reality
Patch the vulnerability	Document who knew what when, regulatory notifications needed, board-level communication
Block the malicious IP	Preserve chain of custody for potential litigation, customer impact assessment
Restore from backup	Legal review before restoration (could destroy evidence), privacy considerations

Your playbook needs to account for both. A purely technical response without compliance awareness can expose your organization to legal risk. Just as a purely compliance-first approach can let an attacker maintain persistence.

What Developers Bring to GRC That Lawyers Don't Understand

Coming from a coding background into GRC, here's where I see gaps:

Automation culture: We document manually when we should script our governance checks. Why write a quarterly audit report you'll rewrite next quarter? Automate it.
API-driven thinking: Your controls can be tested programmatically. Infrastructure as Code meets Control as Code.
Debugging mindset: When a control fails, treat it like a bug. Root cause analysis, fix, prevent recurrence. Not "someone didn't check the box."

The Detection Stack Every Dev Team Should Know

For teams building detection capabilities, keep it practical:

Baseline first: Define normal before looking for abnormal
Correlation over volume: 10 relevant logs beat 10,000 irrelevant ones
Playbook readiness: Can your team execute the response without stopping to figure out who has authorization?
Feedback loops: Post-incident reviews that actually change behavior

My Personal Pivot

At 53, making a career shift to GRC wasn't easy. The temptation is to position yourself as someone who "understands tech better than compliance people." Wrong game. The value is being a bridge—translating between engineering reality and governance requirements.

Both sides speak different languages. Both are right from their perspective. Your job is making sure neither gets ignored when lives depend on it.

The Bottom Line

Detection and Incident Response aren't separate domains. They're part of the same system. If you're a developer moving into security or compliance work, you have a unique advantage: you know how systems actually work under the hood. Use that knowledge wisely.

And if you're in traditional GRC reading this: talk to your engineers. They won't tell you everything upfront, but they'll answer your questions if you ask the right way.

Beyond the Hype: Why Your GRC Strategy Fails Without Real Encryption and DLP

Massimiliano B. — Thu, 25 Jun 2026 15:03:12 +0000

Let’s cut through the noise. When we talk about Governance, Risk, and Compliance (GRC), people often throw around buzzwords. But strip away the jargon, and GRC is fundamentally about Data Security. Specifically, two pillars hold this up: Encryption and Data Loss Prevention (DLP).

If you aren't talking about these, you're not doing GRC; you're just doing paperwork.

The Reality of Encryption

Encryption isn't a magic spell that makes data invisible to hackers. It's a mathematical barrier. We use algorithms and keys to scramble data so only the intended audience can read it.

Here’s the hard truth: For a hacker who has stolen your data, decryption is difficult, not impossible. If they get enough time, computing power, or if your key management is sloppy, they will break it. But without encryption, it's trivial. With it, the cost of attack skyrockets. That’s the goal: making the breach too expensive to be worth it.

DLP: Stopping the Bleeding

While encryption protects data once it's gone, DLP (Data Loss Prevention) tries to ensure it never leaves in the first place.

DLP operates on three states of data:

At Rest: Stored on servers, databases, drives.
In Motion: Moving across networks or endpoints.
In Use: Being actively processed by users.

Modern DLP solutions don't just guess. They deploy agents and network monitors to inspect content in real-time, looking for patterns—credit card numbers, PII, or specific intellectual property signatures.

The GRC Nuance: Block vs. Alert This is where most teams fail. If you implement a "Block All" policy immediately, you will create chaos. You'll get thousands of false positives, disrupt business workflows, and force employees to use "Shadow IT" workarounds (like personal email or Dropbox) to get their jobs done. This ironically increases your risk.

The Right Way: Start with an alert-only monitoring phase. Establish a baseline. Tune your rules. Only then, escalate to blocking specific high-risk scenarios (e.g., sending unencrypted customer data to a personal email). Balance security with operational efficiency. If your controls stop the business, they are failed controls.

Identification and Classification

You can't protect what you can't find. Before a single DLP rule is written, you need a Data Classification Policy.

PII (Personal Identifying Information)? Sensitive.
Financial Data? Confidential.
Everything else? Public.

For structured data (databases), tag the columns. For unstructured data (Office documents), use tools like** Microsoft Azure Information Protection (AIP)** to label files automatically. If you don't have this taxonomy, your DLP tool is shooting blind.

Case Study: The Oscorp Incident

Let's look at a fictional but practical scenario.
Oscorp is facing a PR disaster: a leak regarding side effects of a new medication. Norman and Harry Osborn suspect an insider.

Oscorp uses Microsoft 365, Azure, and SharePoint. Here is how a GRC pro can handles the "Insider Threat" response:

The Low-Hanging Fruit: Immediately block USB flash drive access via Group Policy. It's technically free and stops the most common exfiltration method instantly.
Data Discovery: Don't scan everything blindly. Focus on the threat. We know the drug formula lives in a Microsoft SQL database. Scan there first. Then, hunt for related files in SharePoint.
Labeling: Tag all relevant drug data as "Highly Sensitive" using Azure AIP.
DLP Configuration: Since the stack is Microsoft, leverage native DLP. Configure strict rules to prevent copying or sending any file tagged "Highly Sensitive" externally.
Physical Security: Don't forget the analog world. Conduct physical searches for printed docs on desks. If it's on paper, someone can take a photo. Move sensitive physical records to secure cabinets immediately.

The Bottom Line GRC isn't about checking boxes. It's about understanding that data flows, and your job is to control that flow without strangling the company. Encryption slows down the attacker; DLP stops the leak. Do both, but do them smartly.

Security Education and Awareness: Because Not Everyone Is Technical

Massimiliano B. — Wed, 24 Jun 2026 11:36:17 +0000

Security Education and Awareness: Because Not Everyone Is Technical

In most companies, you won't find a workforce made entirely of developers, engineers, or cybersecurity experts. You'll find salespeople, HR professionals, operations managers, customer support teams, and leadership—alongside technical staff.

This diversity is a strength for business, but it creates a critical challenge for security. Technical expertise does not exist uniformly across the organization, and that is precisely why structured Security Education and Awareness is non-negotiable.

We cannot assume that everyone understands the risks inherent in clicking an email link, sharing credentials, or leaving devices unattended. We must build a program that bridges this knowledge gap systematically. Here is the framework we follow:

1. Formal Training: Course Every 12–18 Months

Comprehensive security training should be delivered on a 12 to 18-month cycle. This timeframe strikes a balance:

Frequent enough to keep concepts fresh
Spaced out enough to avoid overwhelming employees
Structured enough to cover core policies, data handling, and incident reporting

Whether someone writes code or manages accounts, everyone needs this foundational knowledge. It ensures baseline understanding across all departments, regardless of technical background.

2. Testing Knowledge in Practice: Phishing and Baiting Tests

Theory alone doesn't guarantee safety. We validate learning through active simulations:

Phishing Tests: Regular fake phishing campaigns measure real-world vulnerability and identify patterns in how different teams respond.
Baiting Tests: Physical and digital baiting scenarios (e.g., suspicious USB drives left in common areas) test attention to detail beyond emails.

These aren't traps—they are diagnostic tools. The goal isn't punishment; it's identifying where additional support is needed before an attacker exploits a gap.

3. Visible Reminders: Flyers

Not every employee will check their inbox daily for security updates. That's why Flyers placed in break rooms, near printers, and at workstations matter. These visual anchors provide quick reminders of critical practices—like how to report a suspicious activity—and keep security visible during routine moments.

4. Ongoing Learning: Internal Blog

Threats evolve faster than any training schedule. An Internal Blog serves as a continuous channel for:

Recent incident summaries and lessons learned
Tips on emerging threats relevant to non-technical roles
Success stories from the team who reported suspicious activity

It transforms security from a one-time event into an ongoing organizational conversation, accessible to everyone regardless of role or technical skill level.

Conclusion

Security isn't just about firewalls, encryption, or secure coding—it's about building a culture where every employee, technical or not, understands their role in protecting the organization.

With a structured approach combining periodic courses, practical testing, visual reminders, and continuous content, we ensure no department gets left behind. Because in the end, security is only as strong as the weakest link—and that link could be anyone, not just the non-technical ones.

IAM Fundamentals for GRC Professionals: Beyond 'Who Can Login

Massimiliano B. — Tue, 23 Jun 2026 12:09:18 +0000

Introduction

As someone transitioning from software development into GRC (Governance, Risk, and Compliance), you quickly discover that Identity and Access Management (IAM) sits at the center of everything. It's not a siloed IT task—it's the control plane of your organization's entire security posture.

This guide breaks down the core IAM concepts every GRC professional needs to master, without pretending you need to become an Active Directory administrator.

TL;DR: IAM = Authentication + Authorization + Lifecycle Management. Your job as GRC isn't to configure it, but to validate that the processes follow design principles like Least Privilege and Separation of Duties.

1. Design Principles That Matter

Before touching any tool, ground yourself in these foundational principles:

Principle of Least Privilege

Users and systems get only the permissions necessary for their function—no more, no longer than needed. This directly reduces blast radius when credentials are compromised.

Separation of Duties (SoD)

No single person controls a complete critical workflow. Example: The person authorizing a payment shouldn't be the same person executing it. In IAM terms: don't allow one admin to create AND approve privileged access without independent review.

GRC Question to Ask: "If one account gets compromised, what can they actually damage?"

2. The IAM Lifecycle Framework

IAM isn't just about logging in. It spans the full identity lifecycle:

Phase	What Happens	GRC Focus Area
Onboarding	New user identity created	Are role-based permissions aligned with job function?
Active Use	Daily authentication/authorization	Is MFA enforced where appropriate? Are privileges reviewed?
Role Change	User transitions internally	Old privileges revoked? SoD still maintained?
Offboarding	User leaves organization	All access removed within defined SLA? Audit trail preserved?

3. Authentication vs. Authorization: Know the Difference

Authentication (Who are you?)

Verifying identity through factors:

Something you know → Password, PIN (weakest alone)
Something you have → Hardware token, smartphone (MFA)
Something you are → Biometrics (fingerprint, iris, face scan)

⚠️ GRC Risk Note: Biometrics are irrevocable. If stolen, you cannot reset your fingerprint like a password. Policies must account for this permanent exposure risk.

Authorization (What can you do?)

Once authenticated, what resources can the user access?

ACL (Access Control Lists) → Binary allow/deny rules tied to resources
RBAC (Role-Based Access Control) → Permissions assigned to roles, not individuals
ABAC (Attribute-Based Access Control) → Dynamic decisions based on context (time, location, device, sensitivity)

4. NIST Password Guidelines: What Changed?

Old school security culture told us:

❌ Force password changes every 90 days
❌ Require special characters and numbers
❌ Lock accounts after minor failures

NIST now recommends:

✅ Minimum length (8+ chars) over arbitrary complexity
✅ Remove mandatory expiration periods (they cause weak patterns)
✅ Screen passwords against breach databases
✅ Lock only after multiple confirmed failed attempts

Source: NIST SP 800-63B

5. Active Directory & PAM: The Real Risks

Active Directory (AD)

Even if you don't administer AD, understand these risks:

Who has "Domain Admin"? This is the crown jewels.
How does cross-domain trust work?
Is there integration with cloud identities (Entra ID / Azure AD)?

PAM (Privileged Access Management)

Admin accounts are the highest-value targets. Your control requirements:

Control	Why It Matters
Minimize privileged accounts	Fewer targets = lower risk surface
Just-In-Time (JIT) access	Elevated rights only when needed
Session recording	Audit trail for forensic investigations
Vault management	No one knows admin passwords—they're retrieved securely
Separate browsing accounts	Admins shouldn't browse email/web with privileged session

6. What GRC Actually Does in IAM

Your value isn't in configuring ACLs. It's in:

Mapping Processes → Ensure onboarding/offboarding timelines meet compliance
Continuous Audit → Regular reviews prove privilege justification exists
Risk Assessment → Weak authentication = high breach risk regardless of firewall strength
Evidence Collection → Documenting controls for auditors (SOC2, ISO 27001, GDPR)

Conclusion

IAM bridges technical implementation and organizational governance. As a GRC professional, your job is to ask whether the IAM process supports business objectives while meeting security requirements—not to configure the tools yourself.

From code to compliance: You're moving from building mechanisms to validating that those mechanisms align with reality, risk appetite, and legal obligations.

References & Further Reading

From Writing Code to Auditing It: A Developer's Pivot into the Three Lines of Defense

Massimiliano B. — Mon, 22 Jun 2026 12:50:41 +0000

For years, my world was defined by clean code, efficient algorithms, and the satisfaction of a build passing on the first try. As a programmer, I viewed security largely as a checklist item: encrypt the data, patch the server, implement the firewall. If it worked, I shipped it.

But now, as I transition into Governance, Risk, and Compliance (GRC), I'm realizing that writing the code is only the beginning. The real challenge isn't just building the house; it's proving to the board that the locks work, the insurance is paid, and the blueprints actually match the construction.

In diving deep into GRC frameworks, one concept fundamentally shifted my perspective: The Three Lines of Defense (3LOD).

As a developer, I used to think I was the whole team. In reality, I was just the First Line of Defense.

The First Line: Operational Management (The Builders)

This is where I spent my entire career. We are the operational managers and developers who own and manage risk day-to-day.

Our Job: Implement controls, manage processes, and ensure compliance with internal policies.
The Mindset Shift: When I was coding, I thought, "I implemented MFA, so we are safe." Now I understand that owning the risk means documenting how I did it, maintaining the evidence, and admitting when a control gap exists. Self-audits aren't just bureaucracy; they are the first step in accountability.

The Second Line: Risk & Compliance (The Overseers)

This was a new concept for me. This layer consists of specialized functions like Risk Management and Compliance. They don't build the systems; they build the framework the builders use.

Their Role: They provide oversight. They develop the risk management frameworks, monitor the effectiveness of the First Line's controls, and advise on emerging threats.
The Developer Blindspot: I used to view compliance teams as blockers slowing down deployment. Now I see them as the architects ensuring the foundation won't crumble under regulatory scrutiny (GDPR, ISO 27001, etc.). They are the independent party ensuring the "security policy" isn't just a PDF gathering dust.

The Third Line: Internal Audit (The Independent Assurers)

This is the final safety net. Internal audit provides independent assurance to senior management and the board.

The Reality Check: They look back at the evidence. Did the First Line actually do what they said? Is the documentation auditable?
Why It Matters: In the "Oscorp" scenario from my study materials, even if the security team says they follow PCI-DSS, a biased internal assessment isn't enough. You need an independent audit to verify. This is where my old code meets its ultimate test: not does it run, but can it be proven to be secure?

The Journey Continues

Moving from programming to GRC feels like moving from playing the violin to conducting the orchestra.

In code, bugs are syntax errors or logic flaws. In GRC, a "bug" is a lack of governance, a misaligned risk appetite, or a failure to document. The tools have changed—from IDEs to risk registers and audit programs—but the goal remains the same: building resilient systems.

For any developer feeling the itch to pivot, don't fear the paperwork. The logic is still there; you're just applying it to a different layer of the stack. You stop asking "How does this work?" and start asking "How do we know it works?"

That's the GRC way.

Why Security Engineers Need to Think Beyond Code

Massimiliano B. — Fri, 19 Jun 2026 12:08:06 +0000

The CIA Triad Isn't Just Jargon. It's Your Daily Reality.

Most developers learn security as an afterthought. You write code first, then maybe add authentication, throw in some encryption if you're being thorough. But by then, you've already baked decisions into your architecture that no patch can undo.

The CIA Triad (Confidentiality, Integrity, Availability) isn't a compliance checkbox. It's a mental framework that should shape how you build from day one. Here's why it matters, especially if you're thinking about moving from pure engineering into Governance, Risk, and Compliance.

Confidentiality: The "Who Can See This?" Question

What it means: Only authorized individuals access information.

What breaks when it fails: Sensitive data leaks, credentials exposed, regulatory nightmares.

The developer reality:

Publicly accessible S3 buckets with financial records
Hard coded API keys in client-side code
Phishing attacks that compromise employee accounts

Takeaway for programmers: I've written systems where I assumed "internal" meant safe. Wrong. Zero-trust isn't just buzzwords, it's assuming breach and designing accordingly. Every endpoint, every database query, every service account deserves scrutiny.

Integrity: The "Can Someone Tamper With This?" Question

What it means: Data remains accurate, unaltered, and reliable.

What breaks when it fails: Decisions based on corrupted data, manipulated audit trails, falsified financial transactions.

The developer reality:

Malicious actors altering transaction logs
Software bugs modifying pricing data
Unauthorized changes to audit records going undetected

Takeaway for programmers: Write immutable logs. Implement cryptographic signatures for critical data. Design systems where tampering is detectable, not just preventable. If you can't verify what happened, you can't prove nothing went wrong.

Availability: The "Is My System Up When People Need It?" Question

What it means: Authorized users can access systems when needed.

What breaks when it fails: Business operations stop, SLA breaches, ransomware lockouts.

The developer reality:

DDoS attacks taking applications offline
Single-point-of-failure servers without failover
Ransomware encrypting critical data

Takeaway for programmers: Resilience isn't optional anymore. Redundancy, failover mechanisms, backup strategies: they're not Dev Ops luxury items. They're business requirements.

Why This Matters for My Career Pivot

I spent years writing code and selling solutions. Now I'm moving into GRC because security isn't just about building secure systems, it's about understanding why they matter to the organization. Developers who understand CIA aren't just safer engineers; they become better communicators with risk teams, auditors, and business stakeholders.

If you're thinking about this transition too: start here. Learn the models first, the tools second. Everything else builds on this foundation.

From Codebase to Boardroom: Why GRC Isn't Just "Red Tape" (And Why Developers Should Care)

Massimiliano B. — Thu, 18 Jun 2026 11:41:28 +0000

If you're a developer or have worked in IT for years, you probably think of GRC (Governance, Risk, and Compliance) as the thing that slows down your deployment pipelines. "Blockers," "useless documentation," "annoying audits." I worked as a programmer before making this pivot, so I know exactly what you mean. But if you look past the surface, GRC is nothing less than the security architecture of the business itself.

Let's be real about it, based on what I've been studying recently.

Governance: It's Not Just Rules; It's Direction

We often confuse governance with bureaucracy. In reality, governance is simply the set of rules and procedures that tell an organization how to manage risk. Think of my favorite metaphor: imagine you are a homeowner.

Governance is installing the alarm system and deciding who has the keys. In the corporate world, this means having a defined security policy and appointing a CISO. Without this, you don't even know what you're protecting.

Risk Management: Finding the Holes in the Wall

Risk isn't an abstract concept; it's mathematical. It's about identifying critical assets (your most valuable data), assessing threats (what thieves can do), and vulnerabilities (where the lock is rusted). As a former developer, you know you can't fix every bug at the same time. You have to prioritize. Risk management does exactly that: it assigns a likelihood and impact rating to each risk. If a bug in the payment module has a "catastrophic" impact but low probability, you handle it differently from a critical authentication bug with high probability. Ignoring this prioritization is like fixing only the front door while the second-floor windows are wide open.

Compliance: The Rules of the Game

This is where many people get stuck. Compliance means adhering to laws like GDPR, PCI-DSS, or ISO 27001. It's not optional. If your company handles credit cards, you must be compliant with PCI-DSS. If you handle European data, you must obey GDPR. Compliance isn't about creating documentation for its own sake; it's ensuring your "house" meets local building codes. An external audit exists precisely for this: to provide unbiased assurance that we aren't lying about how secure we are.

The Role of the Consultant (And Your Future)

Companies need outside eyes. Internal teams can be biased ("we did everything right"). An independent consultant provides that necessary verification. Furthermore, they offer specialized skills to implement complex frameworks like ISO 27001 or CPS234.

Why should you care? With the evolution of cybersecurity, the line between code and compliance is blurring. Knowing how to structure a security policy or map a risk control to a development process (DevSecOps) is what differentiates a programmer from a senior security engineer. GRC isn't the opposite of secure development; it's its backbone.

From Code to Compliance: Why a Senior Developer is Switching to GRC (and What I'm Learning)

Massimiliano B. — Wed, 17 Jun 2026 12:29:33 +0000

For over two decades, my career has lived at the intersection of logic and persuasion.

I started as a software developer, diving deep into the architecture of systems. Later, I moved into B2B and B2C sales, learning how to sell value, manage stakeholders, and close deals. I spoke the language of the engineers and the language of the boardroom.

Today, I am making a deliberate pivot. I am transitioning into Cybersecurity Governance, Risk, and Compliance (GRC).

Why the switch?

The industry is saturated with tools, but starved for professionals who truly understand both the technical implementation and the business necessity of security.

Most GRC professionals struggle to talk to devs. Most devs struggle to understand risk frameworks.
My goal is to be the bridge.

My Plan: "Build in Public"

Starting today, I will be documenting my entire journey of mastering GRC frameworks (starting with ISO 27001 and NIST CSF) through the GRC Mastery program.

I won't just share certificates. I will share:

Technical breakdowns of how compliance requirements map to actual infrastructure.
Risk assessment strategies tailored for agile teams.
Real-world scenarios where sales psychology meets security policy.

What You Can Expect from This Series

Learning Logs: Deep dives into specific modules (e.g., "Understanding the Statement of Applicability").
Practical Templates: Shareable risk registers and policy drafts I create.
Career Insights: How to navigate the job market as a senior professional changing tracks.

Join the Journey

If you are in GRC, development, or risk management, I'd love to hear your thoughts.

What's the biggest misconception developers have about compliance?
How do we better automate evidence collection without slowing down engineering?

Follow along here on Dev.to and on [LinkedIn] as I build this new chapter, one framework at a time.

Disclaimer: I am currently in the learning phase. The views expressed here are based on my current study and personal analysis.