4 min read
Norsk Tipping is Norway’s state-owned gaming operator, running 2,500 to 3,000 production releases a year across iOS, Android, web and backend systems. Like every regulated organisation at scale, the platform team has to hold two things in tension: maintain strict deployment controls that stand up to audit, and keep the path to production open so that 100 engineers can ship safely.
The mechanism that holds the line is the Admission Control System (ACS) - a reusable pipeline that every team uses, and the only pipeline allowed to deploy to a Norsk Tipping environment. Every change is checked against a set of controls (unit tests, peer review, change approval, deployment window, etc) before deployment proceeds, with every decision recorded in Kosli.
Some of those controls are technical. Others are operational. “We don’t want anyone deploying at night, because we want people at work in case something bad happens,” says Erik Weber, one of the senior platform engineers who built ACS. “And we want the operations team to be able to say, hey, right now we have some issues. We don’t want anything new to happen until we have control.”
Putting policy like that into the pipeline is the easy part. The harder problem is what to do when the policy needs to change. The deployment window is a good solution for most situations, but not all of them. A critical security fix might need to ship at 3am. An ongoing incident might mean nothing should change at all. The controls had to be strict and dynamically adjustable, without code changes, without redeployments, and with a complete audit trail of who changed what.
The first instinct was to build a custom backend with a UI for the exceptions: a console where the operations team could open and close deployment windows, grant break-glass approvals to specific teams, or halt all deployments globally. The team rejected the idea quickly.
“We are platform engineers. We looked at what we already have, to see if we could avoid building something from scratch” says Erik. “How can we avoid that responsibility and maintenance work?”
The answer was to model the exceptions as feature flags. Norsk Tipping already runs a feature flag system across its product engineering - with a UI, an access model, and the operational practice of flipping switches in production safely. The same primitive engineers used to roll out features to subsets of users turned out to be the right shape for rolling out exceptions to controls.
The team modelled two controls as feature flags. The first is an emergency bypass, with one toggle per AWS account. When the development team needs to ship outside the allowed window, they call the operations team, who flip the bypass flag for that account. The deployment proceeds, and the flag flips back. The second is an emergency stop — a circuit-breaker that operations can pull during an incident, per AWS account or globally across the estate.
Together they give the operations team a per-landing-zone pass-through switch and a per-landing-zone kill switch, with the same controls available across the entire estate. What makes the design defensible at audit is what happens at the moment of the admission decision. ACS doesn’t hard-code its logic.
For each deployment it records the full picture as evidence in Kosli — the environment configuration, which flags are on or off, the test results, the change ticket status, the deployment time — and the admission rule itself is a Rego policy that Kosli evaluates against that evidence. The policy that ran, every input it received, and the decision it produced are all written to an immutable trail.
That is what an auditor sees. A 3am deployment is not an unexplained exception. It has a trail of evidence showing that the bypass flag was on, that the operations team made the call during a live incident, that the surrounding controls still ran and passed, and that the policy granted admission for exactly that combination of inputs. The exception is part of the record, not a gap in it.
“If it isn’t in Kosli, it hasn’t happened,” Stephan Haugsrud, Head of Software Development and Quality Assurance, has said of the broader system. The break-glass procedure is no exception. The bypass is something that happened, and now there is a record of it — the policy, the inputs, the override, the result, all in one place.
For a team building toward controls as a product, this is the pattern worth copying. Treat the controls themselves as code: policy in Rego, decisions evaluated against captured evidence, outcomes written to an immutable system of record. When you treat the exceptions as runtime configuration, modeled the same way you would model any other feature toggle, you get a flexible governance landscape that maintains strong control. Norsk Tipping’s setup is one of the cleanest examples of that pattern we have seen in production.
