Who Opened the Outbound Door? Egress Logs as Integration Evidence

Most integration designs describe what arrives. They specify the API contract, the schema, the authentication method and the service level. What leaves the estate is often treated as a network matter: a rule requested late, approved by someone in infrastructure, and forgotten once the connection works. That asymmetry is becoming harder to defend. In a UK estate that mixes on-premises systems, hyperscale cloud, payment providers and regulated data flows, an outbound rule is frequently the dependency that determines whether an integration can run at all.

The asymmetry between ingress and egress

Inbound interfaces attract scrutiny because they expose the organisation. They are reviewed, versioned and tested. Outbound connectivity is assumed to be simpler: the workload initiates a connection, the firewall permits it, and the integration proceeds. In practice, that permission may be the least documented part of the entire design.

A release can pass every functional test and still fail because a proxy rule points at a legacy IP address, because a service account has been placed in the wrong security group, or because a SaaS provider has introduced a new endpoint that nobody has authorised. These are not exotic failures. They are routine in estates where integration architects and network teams hold different pictures of the same service.

The argument here is not that network teams should surrender control of firewalls. It is that an egress rule is an interface contract and should carry the same evidence as any other: a named owner, a stated purpose, a data classification, a review date and a test path.

What the logs already record

Firewall, proxy, DNS and flow logs contain more integration documentation than most architecture repositories. A typical proxy record can show the source workload, the service account, the destination host, the port, the TLS server name, the volume of data and the time of day. What it cannot show is intent. That gap is precisely where integration governance belongs.

Reading logs as evidence rather than as operational noise changes the questions asked. Instead of asking whether a rule exists, the integration team can ask which business capability depends on it, which counterparty sits at the destination, and what would break if the rule were withdrawn. A rule that cannot answer those questions is not a controlled interface. It is an unexplained opening.

For UK organisations, the destinations are often familiar: payment gateways, Open Banking endpoints, HMRC services, identity providers, document storage and a long tail of SaaS tools. Each carries a different data classification and a different contractual basis. A single broad egress rule can obscure all of them.

From log lines to named dependencies

The practical first step is to build a dependency register from observed traffic rather than from design documents alone. Sample a representative period, cluster destinations by service and counterparty, and reconcile the result against the configuration management database and the integration catalogue.

Three categories usually emerge. The first is expected and documented. The second is expected but undocumented: the integration works, but no one has recorded the rule as part of the interface. The third is the difficult category: destinations that no current design claims, often left behind by a decommissioned project or a forgotten pilot.

Each entry in the register should carry a rule identifier, an owning team, the business capability served, the data class involved and a review date. Where a service account is used, it should be named after the integration rather than after the server that happens to host it. This is unglamorous work, but it converts an opaque network estate into a set of interfaces that can be governed.

Change evidence and test paths

An egress contract is only credible if changes to it leave evidence. A rule change should be tied to a ticket, an approver, a stated expiry and a test that runs from a production-equivalent network path. Integration tests that execute from a developer laptop or a CI runner outside the target network segment prove very little about outbound connectivity.

Deny-by-default posture is valuable, but it depends on knowing what should be allowed. Without a register, deny-by-default produces either paralysis or a long list of exceptions granted under pressure. With a register, exceptions can be time-bound and reviewed against a known baseline.

Test paths should also cover the less obvious cases: failover routes, proxy auto-configuration, certificate pinning and the behaviour of scheduled batch jobs outside office hours. An integration that works at 10am may fail at 2am if the outbound path depends on a component that is only healthy during business hours.

An audit method that respects operational reality

Audits of egress rules fail when they are conducted as blame exercises. Network teams inherited many rules from projects that no longer exist, and integration teams inherited designs that never mentioned connectivity. The useful framing is archaeological rather than disciplinary.

Start with a 30-day sample. Cluster destinations, compare them with the integration catalogue, and interview the owners of the largest and oldest rules. Ask what would happen if the rule were removed tomorrow. Where the answer is uncertain, schedule a controlled test rather than an immediate closure. Record the outcome in the same register.

The output should be short enough to act on: a list of orphan rules, a list of broad CIDR ranges that could be narrowed, a list of rules with no named owner and a list of integrations whose outbound dependencies are undocumented. That is a workable backlog, not a theoretical maturity model.

Governance that survives staff turnover

Egress ownership erodes quietly. A rule approved by an engineer who has since left the organisation becomes nobody's rule. The defence is to attach ownership to a service or capability rather than to an individual, and to review the register on a fixed cycle alongside other integration assets.

Retirement matters as much as approval. When an integration is decommissioned, its egress rules should be retired in the same sequence, with the same evidence. Otherwise the estate accumulates openings that no design claims and no team defends.

The firewall log is not a peripheral operational artefact. It is a record of what the organisation actually does across its boundaries. Treating it as interface evidence brings outbound connectivity into the same disciplined conversation as APIs, schemas and service levels, where it has always belonged.