<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[When technical problems become accountability problems]]></title><description><![CDATA[<p dir="auto">At some point, most environments stop having purely technical issues.</p>
<p dir="auto">They start having ownership issues.</p>
<p dir="auto">On the surface, everything can look fine:</p>
<ul>
<li>Policies exist</li>
<li>Controls are mapped</li>
<li>Risks are logged</li>
</ul>
<p dir="auto">From an engineering perspective, nothing is obviously broken.</p>
<p dir="auto">Systems run. Changes get deployed. Issues get fixed.</p>
<p dir="auto">But there is a different question that tends to get overlooked:</p>
<p dir="auto">When a decision creates exposure, who actually owns that outcome?</p>
<ul>
<li>Not who implements the change.</li>
<li>Not who maintains the system.</li>
</ul>
<p dir="auto">Who is accountable if that decision is challenged later.</p>
<p dir="auto">That is where things usually become unclear.</p>
<p dir="auto">Decisions are being made every day across infrastructure, security, vendors, and delivery.</p>
<p dir="auto">But ownership is often:</p>
<ul>
<li>implied</li>
<li>spread across teams</li>
<li>or assumed to sit somewhere higher up</li>
</ul>
<p dir="auto">It works until it is tested.</p>
<p dir="auto">And it does get tested, usually by something external:</p>
<ul>
<li>an audit request</li>
<li>a client asking deeper questions</li>
<li>an incident that needs explaining</li>
</ul>
<p dir="auto">At that point, the discussion shifts.</p>
<p dir="auto">It is no longer about how something works.</p>
<p dir="auto">It becomes:</p>
<blockquote>
<p dir="auto">“Who approved this, and why was that decision considered acceptable at the time?”</p>
</blockquote>
<p dir="auto">That is the part many environments are less clear on than they expect.</p>
]]></description><link>https://sudonix.org/topic/737/when-technical-problems-become-accountability-problems</link><generator>RSS for Node</generator><lastBuildDate>Thu, 16 Apr 2026 13:43:08 GMT</lastBuildDate><atom:link href="https://sudonix.org/topic/737.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 26 Mar 2026 16:00:10 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to When technical problems become accountability problems on Thu, 26 Mar 2026 21:44:41 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/phenomlab" aria-label="Profile: phenomlab">@<bdi>phenomlab</bdi></a> this is good. I see this happen a lot. It is unclear because usually it is a group talking and going over things and trying to plan according to the knowledge that they have with what is working and not working now. And yet some time down the road, something new comes out, something changes and now what was possible isn’t and vise versa. I have seen these kinds of situations, and I encourage taking very good notes and making them so they are always accessible to you/your team so that way a search can be done and the notes appear and you know exactly why, what, how and where the decision was made.</p>
<p dir="auto">When I say you, I mean anyone in a position to make decisions that bring about change in whatever area it might be.</p>
]]></description><link>https://sudonix.org/post/10517</link><guid isPermaLink="true">https://sudonix.org/post/10517</guid><dc:creator><![CDATA[Madchatthew]]></dc:creator><pubDate>Thu, 26 Mar 2026 21:44:41 GMT</pubDate></item></channel></rss>