Module 5: Integration Governance and Security

Integration governance and security are often treated as afterthoughts — added to a project in its final weeks before go-live. This is a costly mistake. Security vulnerabilities in integration layers expose not one system but every system connected to them. Governance gaps mean integrations proliferate without oversight until nobody knows what connects to what. This module establishes how to build governance and security into integration architecture from the start.

Establishing Integration Governance Practices

What Integration Governance Is

Integration governance is the set of policies, standards, processes, and controls that ensure integrations are built consistently, remain documented, are secure, and can be managed over their full lifecycle.

Without governance:

• Teams build integrations independently using different patterns, tools, and quality standards
• No central record of what integrates with what (integration sprawl)
• Changing a system becomes high-risk because nobody knows all its consumers
• Security and compliance audits fail because integration flows are undocumented

The Integration Governance Framework

1. Integration Standards Define the standards all integrations must follow:

• Approved integration technologies and platforms
• Mandatory patterns for common scenarios (e.g., "all file-based integrations must use SFTP with key authentication")
• API design standards (naming conventions, versioning, error response format)
• Messaging standards (event schema format, envelope structure, DLQ policy)
• Logging and monitoring standards (what must be logged, what metrics must be captured)

2. Integration Registry Maintain a central registry of all integrations. At minimum, record:

• Integration ID and name
• Source and target systems
• Data entities exchanged
• Technology used
• Owner team
• SLA and criticality
• Current status (design, build, live, deprecated)

The registry is the answer to the question: "If I need to change System A, what else will be affected?"

3. Design Review Process Require all new integrations to pass a design review before build begins. The review checks:

• Compliance with integration standards
• Appropriate pattern selection
• Security design is adequate
• Error handling is complete
• Non-functional requirements are documented and achievable

4. Change Control Any change to an integration interface — a new field, a schema change, a deprecation — must go through change control:

• Notify all consumers of the change
• Provide a migration timeline
• Version the interface to allow gradual migration
• Never make breaking changes without prior notice and a transition period

5. Lifecycle Management Integrations have a lifecycle. Define processes for:

• Onboarding — how new integrations are introduced and registered
• Deprecation — how old integrations are phased out without breaking consumers
• Decommissioning — how integrations are safely removed from the registry and infrastructure

Integration Centre of Excellence (CoE)

Larger organisations establish an Integration CoE — a cross-functional team responsible for:

• Owning and evolving integration standards
• Maintaining the integration registry
• Reviewing integration designs
• Supporting delivery teams with patterns and tooling guidance
• Monitoring the health of the integration estate

Ensuring Compliance and Regulatory Requirements in Integrations

Common Regulatory Frameworks Affecting Integration

GDPR (General Data Protection Regulation)

• Personal data may only be transferred to countries with adequate data protection
• Data subject rights (right to erasure, right to access) must be enforceable in integration flows — you must be able to delete or export a person's data from every system it flows through
• Consent records must be respected — do not flow data to systems the subject has not consented to

HIPAA (Health Insurance Portability and Accountability Act)

• Protected Health Information (PHI) must be encrypted in transit and at rest
• Access to PHI must be logged and auditable
• Business Associate Agreements (BAAs) are required for systems handling PHI

PCI-DSS (Payment Card Industry Data Security Standard)

• Cardholder data must be encrypted and access strictly controlled
• Integration flows that touch card data must be within or protected around the Cardholder Data Environment (CDE)
• Regular vulnerability scanning and penetration testing of integration components

HL7 / FHIR (Healthcare)

• Healthcare data integration increasingly mandates FHIR-compliant APIs
• Patient data must be exchanged using FHIR resources with appropriate consent controls

Compliance by Design

Compliance should be designed into integrations, not verified at audit time:

• Data classification — tag every data field in the integration with its classification (public, internal, confidential, restricted). Apply controls based on classification.
• Data minimisation — only flow the data fields that the target system actually needs. Do not pass entire records when only one field is required.
• Retention policies — messages stored in queues or event stores must be subject to the same retention rules as the data they contain.
• Consent and purpose limitation — before routing data to a new consumer, verify the legal basis for that data sharing.

Implementing Security Measures in Integration Architecture

Defence in Depth for Integration

Do not rely on a single security control. Apply multiple layers:

Internet → API Gateway (auth, rate limit, WAF)
         → Network perimeter (TLS, IP allowlisting)
         → Service mesh (mTLS between services)
         → Application (input validation, authorisation)
         → Data layer (encryption at rest, audit log)

API Security

API Gateway as Security Enforcement Point The API gateway should enforce:

• Authentication (validate tokens or API keys)
• Authorisation (check scopes and permissions)
• Rate limiting (prevent abuse and DoS)
• Input validation (reject malformed requests before they reach backend services)
• TLS termination

OWASP API Security Top 10 — integration-relevant risks:

1. Broken Object-Level Authorization — check that the caller has permission to access the specific resource, not just the API endpoint
2. Excessive Data Exposure — return only the fields the caller needs; never return full objects and let the caller filter
3. Lack of Rate Limiting — without rate limits, integrations can be abused to exhaust backend system resources
4. Broken Function-Level Authorization — admin APIs must be inaccessible to regular service accounts
5. Mass Assignment — do not bind inbound message payloads directly to data model objects

Authentication, Authorisation, and Encryption Techniques

Authentication Between Systems

OAuth 2.0 Client Credentials Flow The standard for service-to-service authentication in modern integration:

1. The calling service authenticates to an authorisation server using its client_id and client_secret
2. The authorisation server returns an access token (JWT)
3. The calling service includes the token in the Authorization: Bearer <token> header of each API call
4. The receiving service validates the token

Integration Service ──► Auth Server (POST /token, client_credentials grant)
                    ◄── Access Token (JWT)
                    ──► Target API (Authorization: Bearer )

Mutual TLS (mTLS) Both parties present and validate certificates. Used when:

• Client certificates are preferred over bearer tokens
• Zero-trust network environments require peer authentication at the transport layer
• Financial services regulations mandate certificate-based authentication

API Keys Simple, widely supported, but less secure than OAuth 2.0 (tokens cannot be revoked easily, keys can leak). Acceptable for internal low-risk integrations or third-party APIs that do not support OAuth.

Service Accounts For integrations that access databases or file systems:

• Use dedicated service accounts (never shared human credentials)
• Apply principle of least privilege — grant only the permissions the integration actually needs
• Rotate credentials regularly using a secrets manager

Authorisation

Authentication answers "who are you?" — authorisation answers "what are you allowed to do?"

Scope-based authorisation (OAuth 2.0 scopes) Define scopes that represent capabilities the integration is permitted to use:

orders.read   — read order data
orders.write  — create and update orders
inventory.read — read inventory levels

Each integration service account is granted only the scopes it needs. An integration that reads orders should never have orders.write scope.

Attribute-Based Access Control (ABAC) More granular than scopes — access decisions factor in attributes of the resource (e.g., "integration service can only read orders from its own region").

Encryption

In Transit

• All integration traffic must use TLS 1.2 minimum; TLS 1.3 preferred
• Validate certificates — disable certificate validation only in isolated development environments, never in staging or production
• For message broker connections (Kafka, Service Bus), use TLS connection strings; never plain text

At Rest

• Messages stored in queues and event stores must be encrypted at rest using platform-managed or customer-managed keys
• For highly sensitive data (PHI, PII, financial), consider payload-level encryption — encrypt the message body before publishing, so even the broker cannot read it

Key Management

• Store encryption keys in a dedicated key management service (Azure Key Vault, AWS KMS, HashiCorp Vault)
• Rotate keys on a schedule
• Never hardcode keys or credentials in application code or configuration files

Auditing and Monitoring Integration Processes

What Must Be Audited

An integration audit trail must capture enough information to answer:

• Did this message get sent?
• Did it arrive?
• Was it processed successfully or did it fail?
• Who (or what) triggered the integration?
• What data was exchanged?

Minimum audit record for each integration transaction:

| Field | Description | |-------|-------------| | Transaction ID | Unique identifier for the end-to-end flow | | Correlation ID | Links related messages across systems | | Source system | Which system sent the message | | Target system | Which system received it | | Message type | What kind of data was exchanged | | Timestamp | When each step occurred | | Status | Success, failed, retried, dead-lettered | | User/Service account | Who initiated the flow | | Error details | If failed, the reason |

Note: For GDPR-regulated data, the audit log itself contains personal data. Apply appropriate retention limits (do not keep audit logs indefinitely) and access controls.

Monitoring

Integration monitoring must cover:

Availability — is the integration running? Alert if an expected flow has not triggered within its scheduled window.

Throughput — how many messages per minute/hour are being processed? Anomalies (too low, too high) indicate problems.

Latency — how long does end-to-end processing take? Degrading latency often indicates a downstream system under load.

Error rate — what percentage of messages are failing? A rising error rate requires immediate investigation.

DLQ depth — any messages in the dead letter queue require investigation; a growing DLQ is a P1 alert.

Dashboards and Alerting

• Build an integration health dashboard visible to both the operations team and business stakeholders
• Configure alerts for: DLQ messages, error rate spikes, latency threshold breaches, integration service heartbeat failures
• Use structured logging (JSON logs with consistent field names) to enable querying and correlation across log sources

Module Summary

• Integration governance requires standards, a registry, design review, change control, and lifecycle management — without these, integration sprawl is inevitable.
• Compliance requirements (GDPR, HIPAA, PCI-DSS) must be designed into integrations via data classification, minimisation, retention policy, and consent controls — not retrofitted at audit time.
• Implement defence in depth: API gateway enforcement, mTLS or OAuth 2.0 for service-to-service auth, TLS for transport, encryption at rest for stored messages, and secrets management for credentials.
• Authorisation must be granular: use OAuth 2.0 scopes and principle of least privilege. Never grant more access than the integration requires.
• Audit every integration transaction with a consistent record: transaction ID, correlation ID, source, target, timestamp, status, and error details. Monitor availability, throughput, latency, error rate, and DLQ depth.

Next: Module 6 — Integration Testing and Deployment