How a change reaches production
A request to add a column, from the moment it is opened to the moment it appears in production. The screens are real product output.
- 0:07 Every piece of work that will touch production, in one list
- 0:14 The script is parsed and the risk band is computed
- 0:21 Which objects will be touched is known in advance
- 0:28 A rule stops the work before it is even saved
- 0:35 The approval path is built from the content of the request
- 0:42 For the approver, the execute button stays closed
- 0:49 For the executor, the approve button is closed as well
- 0:56 The person who pressed the button and the process that ran are recorded separately
- 1:03 The approved text is compared with the text that ran
- 1:10 Did the change really land on the server
- 1:17 Where did this column come from
An emergency change at midnight
Emergency authority shortens approval; it does not remove it. The same intervention closes with the same evidence.
- 0:07 Urgency does not switch the controls off
- 0:14 Turning on the emergency switch changes the policy
- 0:21 A reason and an incident number are mandatory
- 0:28 The product drafts the rollback script itself
- 0:35 An incomplete rollback plan stops the execution
- 0:42 The person on night duty cannot execute their own request
- 0:49 Once the work is done, the question opens
- 0:56 Two questions and one note
- 1:03 Correct use of emergency authority goes on the record
How data leaves production
In most organisations change is controlled and reading is not. This flow shows the reading side.
- 0:07 Run this query and send me the result becomes a record
- 0:14 Reading passes the critical object check as well
- 0:21 The masking decision is visible before the query runs
- 0:28 Asking for an unmasked column requires a justification
- 0:35 The content of the request decides the approval steps
- 0:42 After approval the decision changes in the table
- 0:49 Every column decision carries a reason
- 0:56 Even seeing the password goes on the record
- 1:03 The masking is inside the delivered file
- 1:10 The sensitive column catalogue never looks at production data
What the auditor actually receives
Evidence is not prepared for the audit; it comes out of the work itself and can be verified without the product.
- 0:07 Every event is written into a signed chain
- 0:14 That the chain is unbroken is shown with a button press
- 0:21 Comparison against the sealed copy in a separate database
- 0:28 The anchor: the chain as it stood that day, sealed to the outside
- 0:35 One request's whole lifecycle in a single file
- 0:42 The rule set as it stood when the request was decided
- 0:49 Script digest, risk and data access on one page
- 0:56 The package is verified inside the product
- 1:03 It can also be verified without the product
- 1:10 The report is not prepared for the audit; it comes out of the work
Where rejected requests live
What shows an approval process is working is not what it approves but what it stops. The screens are real product output.
- 0:07 A rejected request is not deleted from the list
- 0:14 Who can reject is decided in advance
- 0:21 Some work never reaches approval
- 0:28 Passing a finding requires a reason
- 0:35 The approver's bar has Reject on it too
- 0:42 A rejection cannot be saved without a reason
- 0:49 A rejected request closes but does not vanish
- 0:56 Did the rejected work get through another way
- 1:03 A rejection is an audit event
- 1:10 The rejection rate shows up in the report
What is on the server before you run
The script was correct the day it was written. What is on the server the day it runs is a separate question. The screens are real product output.
- 0:07 The same script does not mean the same thing on every server
- 0:14 The script is parsed with the real grammar
- 0:21 The objects the script will touch are extracted
- 0:28 Work that touches a critical object is flagged
- 0:35 Every object has a Show Diff next to it
- 0:42 The current definition on the server, before running
- 0:49 The definition states what it does not cover
- 0:56 Who touched this object last
- 1:03 The critical object list is a decision
- 1:10 After it runs, the trace stays on the object
What your SOC team sees
One line in procurement documents: the product must send its own log and its action log to the syslog collector. Six questions sit behind it. The screens and the messages arriving at the collector are real product output.
- 0:07 Several endpoints, each keeping its own marker
- 0:14 The setup is verified with one button, not with guesswork
- 0:21 The actual message that lands on the collector
- 0:28 What gets sent lives inside the product, in four settings
- 0:35 Narrowing the scope is legitimate
- 0:42 The narrowing becomes visible on the endpoint
- 0:49 The narrowing is announced to the SOC with the previous configuration
- 0:56 The same change also sits in the audit trail
- 1:03 When the collector is down the failure is not silent
- 1:10 When the collector returns the backlog flows