01
Permissions and controls
Who can trigger an action? Where is approval required? We examine whether the rules are reflected in configuration and agreed tests.
Why WitnessOps
Understand the finding. Inspect the evidence. Decide what to do.
WitnessOps traces a specific security question through the relevant system, available records and agreed checks. Each finding explains what supports it, why it matters, what remains uncertain and the recommended next step.
What we examine and what you get
02
The actual outcome
What changed in the destination system? We compare the expected result with available records and observations. A success message alone is not enough.
03
Findings you can inspect
Each finding points to the material supporting it. We distinguish observations, inferences and questions the evidence cannot answer.
04
A practical next step
You receive priorities and recommendations. When repair is in scope, the handover includes changes, agreed test results and operating instructions.
Inspect the work
The public demo checks published artifacts and a declared synthetic key rotation. It demonstrates the method; it is not evidence of a real provider action or a customer engagement.
Clear limits on every conclusion
A verification result names the mechanism, checked scope and supporting artifacts. A valid signature does not establish that the underlying action was safe or correct. A scoped review is not compliance certification or whole-environment assurance.
What we agree before work starts
The systems and actions in scope, authorization and access, evidence handling, deliverables, exclusions, price and timing. Implementing changes requires an agreed scope and authorization.
Company background
WitnessOps was founded by Karol Stefanski, previously an engineer at Waystone and Nostra. Professional background on LinkedIn →
Have a system or action in mind?
Start with a short description, without confidential data.