Take over an incident by confirming four things first
Establish impact, active changes, unresolved outcomes and ownership before starting another intervention. A brief read-back can prevent a costly assumption.
Read articleCobnex blogs / Australia
Cobnex blog
AI implementation, software architecture, cloud operations and Australian technology policy.
40 articles in Security and operations
Page 2 of 3
Investigate a record that reappears after recovery
Find the source that recreated the data before deleting it again. Otherwise the next reindex or restore can repeat the same failure.
Read articleUpgrade a foundational library in reviewable steps
Large dependency jumps mix compatibility changes with security work. Map the affected behaviours and keep each released artifact traceable during the transition.
Read articleSplit a shared service account without breaking rare jobs
Move workloads to individual identities using an operation inventory and staged verification. Recent traffic alone will miss some required permissions.
Read articleMove incident records without losing the live incident's owner
Tool changes need a clear authoritative record and working links. Preserve ongoing response state before migrating historical documents.
Read articleIntroduce retention with a dry run that names every destination
Existing data needs policy mapping and review before destructive execution. Roll out in bounded batches and stop when the observed scope differs from the approved one.
Read articleBuild dependencies inherit the build job's reach
Review credentials and network access where third-party code executes. A package excluded from production can still affect the software you deploy.
Read articleReview who can assume the role, not only what it can read
Trust policy and effective resource access form one boundary. Either side can expose data if reviewed in isolation.
Read articleKeep incident notes useful without copying secrets into them
Responders need evidence quickly, but the working record should not become a second store of credentials or unrestricted customer data.
Read articleA retention hold needs authority, scope and a release path
Exceptions can preserve necessary records, but an unowned hold can quietly suspend deletion forever. Treat creation and removal as controlled decisions.
Read articleKeep dependency maintenance small enough to do regularly
Review effort grows when many unrelated updates accumulate. Balance batching with the ability to identify a regression and deploy a verified fix quickly.
Read articleReuse permission patterns without sharing every service's identity
Templates can reduce maintenance while preserving separate authority. One universal role saves configuration work by concentrating unrelated access.
Read articleA concise handover saves more time than another status meeting
Reduce repeated explanation by keeping current state and ownership visible. Automate factual capture while leaving interpretation and decisions with responders.
Read articleBudget for verifying deletion, not just running the delete query
Retention work spans indexes, objects and recovery procedures. Storage savings are only one part of the operating calculation.
Read articleAsk what changed in the lockfile and where it will execute
A dependency review should connect code origin, capabilities and release evidence. Passing tests answer only part of that question.
Read articleAsk for one allowed operation and one denied operation
Policy review needs runtime evidence and a clear workload purpose. Syntax validation cannot establish that the intended boundary works.
Read articleReview whether a stranger could continue this incident
Test the record's operational usefulness. The incoming responder should find current impact, active state and authority without relying on undocumented memory.
Read articleReview the retention promise against a restored system
The design must explain every relevant copy and what happens after failure. A successful normal deletion run is necessary but incomplete evidence.
Read article