<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SOX on A naive bidder</title><link>https://anaivebidder.com/tags/sox/</link><description>Recent content in SOX on A naive bidder</description><language>en-us</language><lastBuildDate>Wed, 30 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://anaivebidder.com/tags/sox/index.xml" rel="self" type="application/rss+xml"/><item><title>Automating compliance with SOX, COSO and SCF</title><link>https://anaivebidder.com/posts/compliance-with-standards/</link><pubDate>Wed, 30 Sep 2026 00:00:00 +0000</pubDate><dc:creator>Ruben Afonso</dc:creator><guid>https://anaivebidder.com/posts/compliance-with-standards/</guid><description>&lt;p&gt;In the previous post, &lt;a href="https://anaivebidder.com/posts/towards-repeatable-compliance/"&gt;Towards Repeatable Compliance&lt;/a&gt;, we explored the basics of a generic framework to define compliance requirements, extract controls and execute them as part of a deterministic verification set.&lt;/p&gt;
&lt;p&gt;That is useful on its own, but we can do better by aligning each of the components involved with industry standards, gaining better integration and reusing existing patterns.&lt;/p&gt;
&lt;p&gt;This post starts from &lt;a href="https://www.govinfo.gov/content/pkg/PLAW-107publ204/pdf/PLAW-107publ204.pdf"&gt;SOX&lt;/a&gt; regulation, and introduces a well-known governance framework (&lt;a href="https://www.coso.org/guidance-on-ic"&gt;COSO&lt;/a&gt;), a set of controls (&lt;a href="https://securecontrolsframework.com/"&gt;SCF&lt;/a&gt;) and a standard format for expressing findings (NIST&amp;rsquo;s &lt;a href="https://pages.nist.gov/OSCAL/"&gt;OSCAL&lt;/a&gt;).&lt;/p&gt;</description></item><item><title>Towards Repeatable Compliance: The Basics</title><link>https://anaivebidder.com/posts/towards-repeatable-compliance/</link><pubDate>Tue, 08 Sep 2026 10:00:00 +0200</pubDate><dc:creator>Ruben Afonso</dc:creator><guid>https://anaivebidder.com/posts/towards-repeatable-compliance/</guid><description>&lt;h2 id="problem-statement"&gt;Problem statement&lt;/h2&gt;
&lt;p&gt;Most teams store requirements as text scattered across Jira, Confluence and Slack. Every notation invented for them — MoSCoW, EARS, Gherkin — makes a requirement clearer. None makes one &lt;em&gt;checkable&lt;/em&gt;: no Jira board can say whether the rule it describes held last March, or which of its own rules has never been tested.&lt;/p&gt;
&lt;p&gt;That mattered less when a human read every ticket before writing code. It matters more now that agents do much of that reading: as I argued in &lt;a href="https://anaivebidder.com/posts/the-pull-request-future-in-the-agentic-era/"&gt;The Pull Request Future in the Agentic Era&lt;/a&gt;, the leverage is moving upstream, to the requirement itself.&lt;/p&gt;</description></item></channel></rss>