Integration Security, Audit, and Operating Model

Goal

The previous section protected integration boundaries from uncontrolled change, load, and replay. This section adds the production responsibilities that make those boundaries trustworthy: identity, access, secrets, data classification, audit, observability, cost, and ownership.

The durable idea is:

Integration is production architecture only when security, audit, and ownership are designed.

The Short Version

Integration moves business facts across trust and ownership boundaries. That means the design must answer more than "Can the data move?"

Integration boundary
  -> Identity and access
  -> Data classification and audit
  -> Observability and support ownership
  -> Cost review
  -> Recovery path

If the system cannot prove who sent data, what data crossed the boundary, which version was used, what failed, who owns recovery, and what it costs to operate, the integration is not production-ready.

Security Controls

Integration security starts with identity and least privilege.

Control	Design Question
Workload identity	Which application, workflow, worker, partner, or user is calling?
Authorization	What is that caller allowed to publish, read, invoke, export, or replay?
Secret handling	Are credentials, certificates, and API keys stored, rotated, and audited safely?
Network path	Is the boundary public, private, hybrid, partner-facing, or on-premises?
Data classification	Does the payload contain customer data, payment references, tax records, seller data, support notes, or sensitive business data?
Payload policy	Should the integration send full data, a reference, a tokenized value, or a summary?

Do not treat messaging and workflow paths as automatically safer than APIs. A queue, topic, event subscription, connector, or file location can leak sensitive data or allow unauthorized actions if identity and authorization are vague.

Audit Evidence

Audit evidence helps the business prove what happened. It is not the same as logging every payload.

Useful audit evidence may include:

Request, message, event, workflow, file, or export identifiers.
Sender and receiver identities.
Contract name and version.
Business key, such as order, refund, shipment, invoice, or settlement ID.
Timestamps for receipt, validation, processing, acknowledgement, failure, replay, and correction.
Decision outcome and responsible owner.
Operator action when manual review or replay occurred.

The design should avoid storing sensitive payloads everywhere. Often the right audit record stores identifiers, hashes, summaries, references, status, and decision metadata rather than full request and response bodies.

Observability and Support Signals

Integration observability should combine technical and business signals.

Signal	What It Helps Explain
Request rate and latency	Whether APIs or partner calls are healthy.
Queue depth and oldest message age	Whether durable work is backing up and how long business work is waiting.
Retry and dead-letter counts	Whether work is failing, invalid, duplicated, or blocked.
Event delivery and consumer lag	Whether subscribers are behind.
Workflow state counts	How many processes are running, waiting, failed, compensated, or under review.
Contract version usage	Which consumers still depend on old versions.
Replay and correction activity	Who recovered data and why.
Business outcome metrics	Which orders, payments, shipments, sellers, customers, or invoices are affected.

Technical signals without business correlation are hard for support teams to use. Business signals without technical detail are hard for engineering teams to repair. Integration observability needs both.

Ownership Model

Enterprise integration often has shared platform teams and domain teams. The split should be explicit.

Owner	Owns	Should Not Own Alone
Integration platform team	Gateways, messaging infrastructure, workflow platform, shared standards, onboarding guardrails, monitoring patterns.	Business meaning of every contract.
Domain team	Contract meaning, validation, business failure behavior, customer or partner impact, support interpretation.	Shared platform reliability and cross-cutting integration controls.
Security and compliance	Identity standards, data classification, secret handling, audit requirements, access review.	Day-to-day business triage.
Operations or SRE	Alerting, incident response, dashboards, runbooks, escalation coordination.	Domain-specific correction decisions without business owner involvement.

When an integration fails, the runbook should say who checks the platform, who checks the business contract, who decides whether replay is safe, and who communicates impact.

Cost Behavior

Integration cost grows in many places:

API gateway calls and policy processing.
Workflow runs, connector actions, retries, and long-running state.
Broker operations, stored messages, topics, subscriptions, and dead-letter storage.
Event routing and high-volume stream ingestion.
Logs, traces, metrics, dashboards, and retention.
Data storage for audit, replay, reconciliation, and export history.
Partner overage, throttling penalties, or support costs.

Cost review should be part of the operating model. A failure loop that retries every minute, logs every payload, and triggers several workflows can become expensive while still failing to complete the business process.

Example: Payment Settlement and ERP

Payment settlement integration may move finance-sensitive records from commerce into ERP. The design needs strict identity, least-privilege access, data classification, validation, reconciliation totals, audit evidence, and support ownership.

If an export fails, finance needs to know which settlement run was affected, which records were included, whether the ERP accepted or rejected the file, whether replay is safe, and whether correction entries are needed. Engineering needs correlation IDs, logs, workflow state, retry history, and platform health. Security needs to know who can access the data and who can replay or correct it.

The integration is operable when those views are designed together.

Common Mistakes

Treating integration as plumbing with no business owner. The data has business meaning even when the transport is technical.
Storing partner secrets without rotation and access review. Credentials are part of the architecture lifecycle.
Logging sensitive payloads without retention and privacy decisions. More logs can create more risk.
Ignoring cost until retries and logs grow. Integration failures can multiply cost quickly.
Giving replay controls to everyone or no one. Replay should be authorized, scoped, audited, and owned.

If Someone Asks You

What makes integration architecture operable?

A good answer is:

Integration architecture is operable when each boundary has clear identity, authorization, data classification, secret handling, audit evidence, observability, owner responsibilities, runbooks, replay controls, and cost visibility. The design must connect technical failures to business impact so teams can recover safely.

What You Should Remember

Integration needs security, evidence, ownership, and recovery paths.

Questions to Check Understanding

Why is audit part of integration architecture?
Which security controls matter at integration boundaries?
Where can integration cost grow?