The Software Vendor Touching a Customer's Production: Where Should the Evidence Live?
The evidence should live on the customer's own network under the customer's control, but the supplier must be able to reach it.
Read →These articles were written to help teams facing the same problems, not to praise a product. Each one ends with a concrete checklist you can apply.
The evidence should live on the customer's own network under the customer's control, but the supplier must be able to reach it.
Read →Evidence is the only thing that protects the DBA after an incident. The person with the most access is the easiest to blame.
Read →Most organisations manage the moment of exit. Once the file has left, no system follows its life.
Read →The riskiest work is the least recorded work. The fix is not to switch on blocking but to record the decision and evidence while the DBA does the job.
Read →"The AI made a mistake" is the wrong sentence. The right one: the key handed to the agent made the mistake. Three layers: enforce, route through a gate, monitor.
Read →The rule is written on your own platform with your own risk appetite. The product supplies three things: the expected accounts report, the session tag and start and end events.
Read →Removing standing privilege is easy; removing emergencies is impossible. The emergency path should be made provable rather than abolished.
Read →DAM sees everything but does not know what was approved. The process system knows what was approved but does not see the rest. The two gaps are two halves of the same story.
Read →Access answers one question: what can they do. Justification answers another: why did they do it. In most organisations the second is recorded nowhere.
Read →There is no bad intent and no record either. No product can stop the paste, but it can reduce what is available to paste.
Read →Authenticating tells who someone is. It does not say what they may do.
Read →A ticket approves the intent. The text that runs lives somewhere else.
Read →A system's records must also exist somewhere the people who run that system cannot change.
Read →A control written in a procedure but not enforced by the system is not a control, it is a wish.
Read →A script does not say change this line. It says this object is now the following. The object may have changed in between.
Read →If a gate has never turned anyone away, there is no way to know whether it is locked.
Read →An audit record is kept long because it is evidence; a query result file is kept briefly because it is risk.
Read →A rule enabled two weeks before the audit produces no evidence for a full year period.
Read →A backup is a photograph of data. It does not contain the decision taken before the photograph.
Read →Twenty items means as many as can be reviewed in the time allotted. That is a budget decision.
Read →A log platform tells you an event happened. It cannot tell you whether it was permitted.
Read →If the key is stored in a table, the person who wants to alter the chain is already there.
Read →Someone who can change the server clock can produce evidence that passes every check and still carries a false date.
Read →The digest that counts is one that has sat in a locked store since the day it was written.
Read →If the party making the claim is the party keeping the records, the claim is not evidence.
Read →A monitor is a camera, governance is a turnstile. Needing both does not mean either one is inadequate.
Read →A developer writing an unqualified delete hesitates. An assistant producing the same statement does not.
Read →An approval step means something because it can say no. If it never does, it is not a gate but a counter.
Read →A customer asked for erasure. It was deleted from production. What about the copies in test?
Read →A script can be entirely correct and still dangerous enough to stop production.
Read →Without its third property, what you hold is an event log rather than an audit trail.
Read →A pipeline knows what it carried and stays silent about what it did not. That silence reads as nothing happened.
Read →An account left from a project that ended years ago is still open and still privileged. Nobody knows whose it is.
Read →A process may be working, but if it produces no evidence the audit outcome is the same.
Read →The frameworks include it in scope; the design was built around application releases. That is where it breaks.
Read →The question is not whether you can. It is whether this is your core business and whether you will maintain it for five years.
Read →If a board has rejected nothing in months, the submissions are not flawless. The board has no time.
Read →The eight steps of the process, who does what in each, and four maturity levels.
Read →Not every eleven digit number is an identity number. Does the name decide, or the content?
Read →A permission granted too broadly breaks nothing; it only lets someone see what they should not.
Read →The application and network sides are usually mature. Friction tends to appear in database operations.
Read →The control exists but the evidence does not. What four Annex A controls mean at the database layer.
Read →What stalls an audit is not missing records but records that do not answer the question.
Read →Why does a script that passes in test fail in production? Schema drift and how to detect it.
Read →The pipeline is built, the scope is not. The eight paths into production and how many are really governed.
Read →Four systems, four half answers. The invisible cost of assembling evidence by hand, and the single record model.
Read →Why a screenshot is weak evidence, and what a per request sealed file puts in its place.
Read →The ticket says what was asked, the log says what ran. What connects the two?
Read →An emergency change is not skipping approval. A separate policy, a locked step and a declaration threshold.
Read →Seven steps to turn the request into a process, and how the masking decision is made.
Read →The 12 evidence items, where each comes from, and what does not count as evidence.
Read →Why it keeps repeating, and how to build four independent layers of defence.
Read →Implicit commit, transaction boundaries and how to build a realistic rollback plan.
Read →The band approach, non skippable rules and an explainable decision.
Read →How SoD works in small teams, the emergency exception and what auditors check.
Read →A wrong request can be undone. What a relaxed control missed while it was off cannot be recovered.
Read →The ledger, the digest outside, independent verification and the limits worth admitting.
Read →If you want to apply these checklists in your own environment, let us start with a 30 minute demo.
Book a Demo →