# How Should Organizations Govern Cross-System Integration and Case Management?

issues.house · September 30, 2026

> Direct Answer ILM integration governance should mean the managed combination of systems, data, responsibilities, controls, and service processes used...

## Direct Answer

ILM integration governance should mean the managed combination of systems, data, responsibilities, controls, and service processes used by an Integrated Landscape Management program. It is broader than connecting technical interfaces: the governing body must decide what is being integrated, which records are authoritative, who may access or change them, how exceptions are handled, and whether operational performance and compliance requirements are being met. For a support, compliance, or public-affairs organization, the equivalent pattern applies to a case house that receives requests from channels such as email, web forms, CRM systems, regulatory portals, and partner tools.

**Also worth reading:** [How Do Modern Organizations Design an Enterprise Issue Management Workflow?](https://issues.house/knowledge/how_do_modern_organizations_design_an_enterprise_issue_management_workflow.php) · [What is enterprise agentic control plane architecture and how do organizations govern multi-agent AI systems?](https://issues.house/knowledge/what_is_enterprise_agentic_control_plane_architecture_and_how_do_organizations_govern_multi-agent_ai_systems.php) · [How Should Organizations Conduct a Case Platform Security Review in 2026?](https://issues.house/knowledge/how_should_organizations_conduct_a_case_platform_security_review_in_2026.php)

As of 30 September 2026, there is no universal product or methodology called “ILM integration governance.” The acronym is commonly used for Integrated Landscape Management, including Mozambique’s World Bank-supported portfolio, but it can also be used internally for information lifecycle management or another organization-specific term. Governance should therefore begin by defining the expansion of ILM in the governing documents. A sound model normally has four layers: architecture, data ownership, operational controls, and oversight. Integration without those four layers can make information move faster while leaving ownership, accuracy, security, and accountability behind.

## What ILM Integration Governance Actually Covers

An ILM program typically coordinates activities across adjoining geographic or administrative areas rather than treating each intervention as an isolated project. Mozambique’s Integrated Landscape Management Portfolio illustrates that public-sector context, where shared boundaries, institutional mandates, community participation, and investment planning create dependencies. In a case-management setting, the functional analogy is a shared matter that crosses systems and teams. For example, a public-affairs case may begin in a CRM, receive supporting material in a document repository, generate a compliance review, and become a formal action item in a workflow system.

The governance scope should include the intake contract, system roles, identity and access model, common identifiers, data definitions, retention requirements, hand-offs, monitoring, incident response, and closure criteria. It should also establish decision rights. Technical teams may own connectors and uptime, while business teams own case quality, data classification, and service outcomes. Compliance or legal staff may set restrictions, but they should not become an unrecorded bottleneck for every routine update. The design is effective when responsibility is explicit enough to audit and simple enough for staff to apply during normal operations.

A useful distinction is between connectivity and coordinated operation. A successful API call proves that two systems exchanged a payload; it does not prove that duplicate records were prevented, the correct owner accepted the case, or downstream controls were executed. ILM integration governance addresses the whole service chain. It defines whether an integration failure is merely technical, whether the resulting case may still be worked on, when a manual fallback is permitted, and how long an exception may remain open.

## Governance Model and Accountability

A workable model separates governance into decision-making, control operation, and assurance. A steering group approves scope, risk tolerance, architecture principles, major spending, and policy exceptions. Operational owners control configurations, access rights, data-quality rules, queue management, and hand-offs. Independent assurance, through internal audit, compliance testing, security review, or periodic sampling, checks whether the controls work as intended. This separation prevents the people who configure a workflow from being the only people deciding whether the workflow meets policy.

Each material integration should have a named business owner, technical owner, data owner, security or privacy owner, and support owner. Smaller organizations can combine these roles, but they should not combine them so completely that one person controls creation, approval, operation, and review of the same control. The governance body should meet on a defined cadence: monthly may suit active operational issues, while quarterly may be adequate for low-change programs. Urgent exceptions require a separate route with post-event review rather than an informal decision that disappears into chat messages.

A concise RACI-style allocation is useful internally even if it is not published as a formal matrix. One party is responsible for execution, one is accountable for the outcome, affected functions are consulted, and others are informed. The critical point is to avoid assigning “integration” as an undifferentiated responsibility to an IT department. Business owners must remain accountable for data meaning and case outcomes, while technical owners remain responsible for availability, interfaces, and telemetry.

| Feature | Program-level governance | Case-house operations | Audit or compliance review |
| --- | --- | --- | --- |
| Primary purpose | Set scope, policy, risk tolerance, and investment priorities | Manage cases, evidence, hand-offs, deadlines, and service quality | Test compliance, segregation of duties, retention, and evidence quality |
| Typical cadence | Monthly or quarterly | Daily or weekly | Quarterly, annually, or after a major change |
| Decision rights | Approves models and exceptions | Accepts and routes individual cases | Escalates deficiencies and verifies remediation |
| Main evidence | Architecture decisions, risk register, service metrics | Case histories, access logs, quality checks, closure records | Samples, test results, control findings, remediation records |
| Common failure | Policy exists but ownership is vague | Workarounds bypass designed controls | Review occurs too late to prevent operational harm |

## Implementation Steps for an Issue House
The first step is to map the current service rather than beginning with a procurement decision. Document where cases originate, what identifiers are assigned, where status changes, which systems contain duplicate copies, and where staff re-enter information. A practical baseline for a medium-sized operation might include 5 to 10 major intake and work systems, but the number matters less than the dependencies. During discovery, teams should measure manual re-entry, average hand-off time, duplicate rates, unauthorized access events, and the percentage of cases with incomplete audit trails.

The second step is to define a canonical case model. Every issue should receive a stable internal identifier, while external references from regulators, partners, or legacy systems should be stored as searchable aliases. The model should specify required fields, permissible values, status meanings, confidentiality levels, ownership rules, and retention dates. Dates should be represented consistently across time zones, and statuses should distinguish “received,” “under review,” “awaiting information,” “action approved,” and “closed” rather than relying on labels that mean different things in different tools.

The third step is to build a minimum viable control set before automating decisions. This normally includes role-based access, least privilege, encryption in transit, logging, backup, tested recovery, change approval, and documented retention. Risk-based additions may include dual approval for high-impact actions, segregation between case creation and final closure, enhanced review for sensitive records, and data-loss-prevention controls. Automation should not automatically approve cases merely because a model scored them highly; confidence scores and probabilistic outputs require human review whenever consequences are material.

The final step is staged implementation with measurable gates. Begin with read-only synchronization or a small number of low-risk fields, then compare outcomes with the existing process. Expansion should require stable identifiers, acceptable duplicate rates, complete audit logs, tested support procedures, and demonstrated recovery. A reasonable initial service target could be 99.5% availability for a non-critical internal integration and 99.9% for a system supporting externally committed deadlines, but targets must reflect business impact rather than copy a vendor benchmark.

## Controls, Data Quality, and Security

Integration governance fails most often when technical correctness is confused with trustworthy data. A connector may transmit every field perfectly while preserving an obsolete address, attaching evidence to the wrong case, or updating a record after a legal hold should have frozen it. Data-quality rules should therefore operate at creation, transformation, transfer, and closure. Examples include checking country and date formats, preventing duplicate external references, validating case-category codes, and reconciling status changes against approved workflow transitions.

Controls should be proportionate to harm. Public information, internal support data, and legally protected records do not justify identical access controls. A useful access review interval is quarterly for privileged roles and annually for ordinary roles, with immediate review after termination or a major role change. Service accounts should have individual owners, limited permissions, rotated credentials where supported, and logs that distinguish machine actions from human actions. Direct database access by routine integrations should be avoided because it bypasses much of the application’s validation and audit logic.

Security controls must include failure behavior. When a downstream regulator’s portal is unavailable, teams need to decide whether cases can enter a controlled offline queue, how long records may be held locally, and when staff must notify affected stakeholders. Automatic retries can duplicate actions, so they require idempotency or duplicate detection. A common threshold is no more than three retries with exponential backoff, followed by manual escalation, although the correct number depends on the transaction and system limits.

Data minimization should guide synchronization. Sending only fields required for a defined purpose reduces exposure, but it must be balanced against operational usability. Omitting evidence or decision history may make the record legally or operationally incomplete. The governance decision should document why each data class is needed, who can use it, how long it is retained, and what happens when its purpose ends. This is more reliable than sending an entire customer record to every connected tool.

## Alternatives and Trade-Offs

Organizations have several viable approaches. A lightweight shared case model is best when teams are small, change frequently, and use only a few systems. A centralized integration platform provides stronger orchestration and observability when many APIs, queues, and transformations exist. A specialist case-management platform offers stronger workflow, evidence, and audit functions when compliance deadlines dominate. Manual coordination remains unavoidable in some low-volume or exceptional situations, but it should use documented templates and reconciliation rather than untracked spreadsheets.

Building every capability internally offers maximum control but creates long-term maintenance obligations. Buying a commercial suite can reduce time to deployment, yet configuration, data migration, licensing, and process redesign may still represent 60% or more of the first-year effort. Open-source integration tools may lower direct license costs, but they do not eliminate labor, hosting, security patching, monitoring, or support expenses. Managed iPaaS products can reduce connector upkeep, although recurring fees, vendor lock-in, data-residency terms, and API limits require review.

| Option | Advantages | Limitations | Suitable use |
| --- | --- | --- | --- |
| Shared spreadsheet or database | Fast, inexpensive, familiar | Weak controls, poor auditability, difficult concurrency | Small team or temporary prototype |
| Custom-built integration | Maximum process fit and control | High engineering cost and maintenance burden | Stable, specialized requirements |
| Open-source workflow stack | Flexible licensing and deployment | Requires technical operations and governance expertise | Organizations with capable engineering resources |
| Commercial case-management suite | Workflow, permissions, reporting, vendor support | Configuration complexity and recurring cost | Compliance-heavy, multi-team operations |
| Managed integration platform | Prebuilt connectors and monitoring | Subscription fees, limits, vendor dependency | Connecting many standard business systems |

No alternative removes governance. A commercial platform can encode poor decisions, while an open-source system can implement excellent controls. Selection should be based on case complexity, regulatory obligations, integration count, available skills, and total operating cost over at least three years.

## Cost, Timing, and Decision Thresholds

Costs vary sharply by scale. A small internal pilot using existing tools might cost roughly $5,000 to $25,000, mainly for configuration, testing, training, and limited data cleanup. A production-grade integration among several commercial systems may cost $50,000 to $250,000, while a regulated organization with multiple regions, custom connectors, migration, and assurance can exceed $500,000. Annual operating costs may be 15% to 30% of initial implementation cost for maintenance, licenses, hosting, support, and control testing, though highly customized environments can cost more.

Schedule estimates should include discovery and business process work, not only coding. A narrow pilot may take 8 to 12 weeks. A multi-system implementation commonly takes 4 to 9 months, and complex migrations or public-sector deployments may require 9 to 18 months. Agencies should allow 20% to 30% contingency when legacy data or institutional responsibilities are uncertain. Procurement that promises a fixed date without completing data mapping and access reviews is creating schedule risk.

Decision thresholds help prevent unnecessary scale. Manual coordination is acceptable when volume is low, actions are reversible, and records can be reconciled. Integration is warranted when the same information is repeatedly copied, delays threaten deadlines, conflicting versions affect decisions, or audit requirements demand a unified history. A dedicated platform becomes justified when multiple channels feed common workflows, access must be strictly controlled, and operational reporting cannot be produced reliably from spreadsheets. These are decision signals, not universal numerical rules; organizations should test them against their own risk and service performance.

## Common Mistakes and When to Act

The most common mistake is waiting for a major incident before defining ownership. Another is buying a platform before agreeing on case definitions and decision rights. Teams also underestimate migration quality, underfund exception handling, and treat observability as optional. Excessive governance is equally damaging: requiring a committee meeting for a low-risk status update can slow the service without improving control.

Immediate action is appropriate when there is evidence of unauthorized access, unreconciled payments or regulated actions, repeated duplicate submissions, missing audit history, or unrecoverable records. Teams should contain the affected workflow, preserve evidence, identify the affected cases, and use a documented continuity process. They should not erase or overwrite potentially relevant records while investigating.

For planned improvement, act when a service review shows a sustained defect, not simply because a fashionable integration technology is available. A review every six months can track availability, duplicate rate, first-response time, median resolution time, percentage of cases closed within deadline, exception aging, and percentage of records passing required quality checks. Examples might be reducing duplicate case creation below 0.5%, keeping 95% of routine hand-offs within two business days, and ensuring at least 98% of material actions have complete actor and timestamp records. The correct values depend on risk, but unreported targets guarantee that performance cannot be managed.

The final step is periodic revalidation. Systems, regulations, vendors, and organizational responsibilities change, so a control approved two years earlier may no longer match current operations. Annual policy review, event-driven architecture review, and quarterly access review can be combined pragmatically for smaller teams. By 30 September 2026, a credible governance program should produce not only connected software, but also current architecture records, named owners, tested controls, measurable service outcomes, and evidence that people can work safely when one integration fails.

## Quick answers

### Is ILM integration governance a recognized industry standard?

There is no single universal standard carrying that exact name. ILM commonly refers to Integrated Landscape Management, while governance models for integration are usually assembled from project management, data stewardship, cybersecurity, audit, and change-management practices.

### Who should own integration governance?

Ownership should be shared, with one accountable executive or program owner and named business, technical, data, and control owners. IT alone cannot decide case meaning, regulatory treatment, or whether an operational outcome is acceptable.

### How much does ILM integration governance cost?

A narrow internal pilot may cost $5,000 to $25,000, while a multi-system production program may cost $50,000 to $250,000. Regulated, highly customized programs can exceed $500,000, especially when migration, regional deployment, and assurance are included.

### What is the first control an organization should implement?

Start with clear ownership, a stable case identifier, role-based access, and end-to-end audit logging. These fundamentals usually provide more value than adding many automated connectors before basic data definitions and responsibilities are settled.

### When is an integration platform worth the investment?

A platform is generally justified when several systems feed shared cases, manual copying causes errors, access must be tightly controlled, and reporting depends on consistent data. For a small team with low volume and simple workflows, controlled manual or shared-database processes may be cheaper and sufficient.

Canonical: https://issues.house/knowledge/how_should_organizations_govern_cross-system_integration_and_case_management.php
Markdown: https://issues.house/knowledge/how_should_organizations_govern_cross-system_integration_and_case_management.php/index.md