What Practitioners Actually Think About Security Regulation

Where this comes from

Cloud Security Office Hours is a free, open Zoom that runs every Friday. Practitioners drop in, someone asks a question, the room works through it, and every session gets a published recap. Regulation surfaces constantly in passing. This page draws on the six sessions where the group actually argued about it, including a May 2025 session given over to a guest presentation by a technology lawyer.

This is not a survey, not a consensus document, and emphatically not legal advice. It is what people said to peers rather than to a camera. No attendee is named apart from a guest who presented publicly. Where sessions contradicted each other, both views are here. Regulation also moves faster than this page will: treat every specific requirement mentioned as of its session date and verify the current state before acting on it.

Do penalties actually change behavior?

The June 26, 2026 session is the one to read if you read only one. The group weighed whether legislation and fines meaningfully change how organizations behave, and the answer that emerged was mostly no, for two separate reasons.

The first is that large organizations absorb fines as a cost of doing business. Some attendees argued fines are still a reasonable starting point, and nobody claimed they were worthless, but the room was clear that a penalty an organization can budget for is a price rather than a deterrent. GDPR and Sarbanes-Oxley came up as cases where penalties are levied but, in the view expressed, rarely paid in full.

The second reason is more uncomfortable, because it is about the public rather than the regulator: the observation was made that reputational damage from breaches has faded as consumers grow desensitized. If the market stopped punishing breaches, then the informal enforcement mechanism that regulation was supposed to supplement is no longer doing much either.

The alternative floated in that session, and the single most repeated idea on this page, is personal liability for CISOs and executives, on the reasoning that an individual cannot absorb a penalty the way a balance sheet can. Nobody worked through what that would do to the willingness of anyone to take a CISO job, which is the obvious counterargument and did not get made.

The same session added a forward-looking note from an attendee speaking from direct experience: software liability frameworks written for an earlier era may need revisiting now that AI systems operate at global scale.

What regulation has actually changed

Set against that cynicism is a case where regulation demonstrably moved engineering practice, and it is worth noticing that it did not work through penalties at all. It worked by requiring an artifact.

The May 1, 2026 session discussed the software bill of materials as something that arrived to a skeptical reception and now has legitimate demand and real use behind it, with the European Cyber Resilience Act named as the driver and CycloneDX and SPDX as the formats. The March 6, 2026 session traced the same arc back further, noting that SBOM requirements accelerated after the SolarWinds compromise.

That session also named the cost of this approach in one phrase: the tension between regulatory demand and practical implementation. Mandating an artifact is easy to legislate and easy to audit, which is exactly why regulators reach for it, and it produces compliance long before it produces security. The complaint in these sessions is never that SBOMs were required, it is that having one is not the same as using one.

The fuller argument about whether SBOMs earn their keep is on the supply chain digest. What matters here is the mechanism: of everything discussed across these six sessions, the requirement to produce a specific document is the only regulatory instrument anyone credits with changing what engineering teams actually do.

Frameworks written for somebody else

A recurring practical complaint is that the best available guidance is addressed to an audience most attendees are not part of. The June 12, 2026 session worked through CISA's binding operational directive and its stakeholder-specific vulnerability categorization approach, which prioritizes by exposure, known exploitation, automatability, and impact rather than by severity score.

The room's reaction was not that the framework is wrong. It was that CISA writes for federal agencies, so any non-federal organization wanting to adopt it has to do custom work mapping it onto whichever compliance regime it already answers to. That mapping cost is invisible in the directive itself and lands entirely on the adopter.

The same session flagged the three-day patching expectation for high-risk vulnerabilities as difficult to meet in practice, which is the other half of the same problem: a requirement calibrated for one operating model becomes an aspiration in another.

This is a mild but real defense of regulation, incidentally. Federal directives function as free, well-researched guidance that the rest of the industry borrows from, and nobody in the session suggested ignoring it. The complaint is about translation cost, not legitimacy.

The contract is the control

The most substantive treatment of regulation in the archive came from a guest. In the May 23, 2025 session, technology lawyer Jay Seirmarco presented on where cybersecurity, contracts, and regulation meet, and the through-line was that the enforceable unit is usually the contract rather than the statute.

The organizing concept was purpose: what a given piece of data was collected for, and therefore what it may lawfully be used for later. Two case studies illustrated the failure mode, one involving insufficient user consent for data sharing and another involving retention of voice recordings for AI training. The practical prescriptions were clear data segmentation, purpose-based processing, and documenting metadata, all of which are engineering work rather than legal work.

The idea most worth carrying out of that session is synthetic and derivative data: data generated from an existing dataset using AI or other methods. The point made was that you have to trace back to the original data's source and consent, because a derived dataset does not shed the constraints of what it came from. That is a genuinely hard technical problem disguised as a paperwork problem.

On jurisdiction, the session noted that European data protection law is more strictly enforced while US state laws have adopted similar terminology, that federal AI regulation may preempt state law, and that companies need to track data flows across jurisdictions and obtain appropriate consent. The closing observation was that contracts will have to specify rights and limitations far more precisely, because they are increasingly being asked to cover uses that did not exist when they were signed.

Enforcing policy on tools people already have

Governance discussions in these sessions keep starting from the same awkward position: the thing being governed is already deployed, usually by people who did not ask. The May 29, 2026 session compared the available enforcement levers for AI tools specifically, covering mobile device management controls, network proxies, and gateways that restrict which models and which data employees can reach.

The most transferable idea there is a distinction that applies well beyond AI. An unintentional policy bypass, where someone works around a control to solve a technical problem, is a design failure and should be fixed in the design. An intentional bypass is a disciplinary matter, and trying to solve it with more technology is a category error. Most policy arguments get easier once you decide which of the two you are looking at.

That session also named the uncomfortable prerequisite: real enforcement depends on a central purchasing function and mature HR processes, neither of which smaller organizations have. Policy without procurement control is a request.

The June 26, 2026 session reached a similar place from the human end, discussing how to extend physical security guidance to home offices without issuing unrealistic policies or simply making people anxious. The recurring theme across both is that a policy nobody can comply with is worse than no policy, because it teaches people that policies are decorative.

Pushing it down the supply chain

Where regulation is hardest to apply directly, the room's practical answer is to make it a procurement question. The March 6, 2026 session included concrete advice on vendor due diligence: ask prospective SaaS providers for their software development and operational lifecycle documentation, and treat that request as part of selection rather than an afterthought.

The same session discussed code escrow, standard tooling for generating and shipping security artifacts (raised from experience in the medical device industry, where this is long-established), and the possibility of sourcing SBOMs from vendors automatically instead of chasing them.

This is a quieter theme than the argument about fines, and arguably a more useful one. A regulator can only reach the entities it has jurisdiction over. A customer with a procurement process can impose requirements on any vendor that wants the contract, which is why the sessions treat vendor questionnaires as a real enforcement mechanism even while treating fines as a weak one.

Where the room disagrees

These are live disagreements, not strawmen. None of them were settled.

Are fines a floor or a fig leaf?

The central split, from the June 26, 2026 session. One position held that fines are a reasonable starting point and that having a penalty regime beats not having one. The other held that large organizations simply price them in, citing GDPR and Sarbanes-Oxley as regimes where penalties are levied but rarely paid in full. Both sides agreed on the underlying facts and disagreed on whether an imperfect deterrent is still worth having.

Would personal executive liability work, or just empty the chair?

Raised in the same session as the more effective alternative to corporate fines, on the logic that an individual cannot expense a penalty. What the room did not do is test it: nobody argued the other side, which is what personal liability would do to the supply of people willing to hold the role, or how it would interact with the reality that CISOs frequently lack the budget authority to fix what they would be liable for. Recorded here as the strongest idea in the session and also the least stress-tested.

Whose responsibility is safe usage?

Also from the June 26, 2026 session, and unresolved: whether the obligation sits with users to select and operate tools sensibly, or with vendors to build tools that non-technical staff cannot hurt themselves with. This is the same argument that runs through the supply chain digest about who owns dependency risk, which suggests it is a structural disagreement rather than a topic-specific one.

Does mandating an artifact produce security or paperwork?

Implicit across the May 1, 2026 and March 6, 2026 sessions. SBOM mandates are credited with genuinely changing engineering practice, and criticized in the same breath for producing artifacts nobody operationalizes. Nobody proposed a regulatory instrument that would compel the second part, and it is not obvious one exists.

FAQ

Is this an official position of Cloud Security Office Hours?

No. It is a synthesis of what attendees said on the live Friday call across six sessions. CSOH is vendor-neutral, takes no position on any specific law or regulation, and nothing here is legal advice. Where attendees disagreed, both sides are reported rather than reconciled, and opinions are labeled as opinions.

Why are no individual attendees named?

The Friday session is open to anyone, but it is a conversation, not a publication. People think out loud, change their minds, and talk about their employers informally. Attributing opinions to named individuals would change what people are willing to say. Guest speakers who presented publicly are named, because presenting is a public act.

How were these sessions selected?

They are the recaps between May 2025 and June 2026 in which regulation, compliance, or liability was actually argued about rather than mentioned in passing. Regulation comes up constantly in the archive; most of those mentions are one line and are not represented here. Every claim on this page links to the recap it came from.

Is any of this legal advice?

No. One session featured a lawyer presenting, and even that is reported as what was said in a community discussion rather than as guidance you can rely on. Regulation also changes faster than this page does, so treat every specific requirement as of its session date and confirm the current position with counsel before acting.

Can I join the Friday session?

Yes. It runs every Friday, it is free, there is no pitch, and there is no requirement to speak. Details are on the sessions page, and every past session has a published recap.