Your technology team hears that the gateway runs inside your own environment. Then security review opens, and nobody can say what that means in servers, firewall rules, secrets, and logs.
Without a written list, the work gets scoped from guesses. Senders wait for access, reviewers ask for evidence nobody collected, and the first payload slips.
This checklist covers what a carrier provisions to run an integration gateway in-house. It walks through five layers: network, identity and secrets, data handling, observability, and ownership. Each layer ends with something a security reviewer asks to see.
What Does Running an Integration Gateway In-House Mean?
An integration gateway is a single, secured entry point that lets outside systems send data into a carrier's core platform without building a separate connector for each sender. Running it in-house means that entry point, and every record passing through it, lives on infrastructure you control.
What Stays Inside Your Perimeter
Payloads, field mappings, request logs, and the insurance-trained AI that drafts mappings all run in your environment. Sensitive policy and claims data stays on infrastructure you control, which is the purpose of running the gateway in-house.
Who Sends and Who Receives
Senders are underwriting workbench vendors, rating vendors, MGAs, MGUs, TPAs, brokers, and agencies. Receivers are the underwriters and adjusters who work the data once it lands. Your infrastructure serves both groups. Each sender is an outside party reaching your network edge, so treat sender onboarding as a security event, not a ticket.
What Are the Five Layers of Gateway Readiness?
The Five-Layer Readiness Check gives every item an owner and a piece of evidence. A layer is done when its owner hands the reviewer that evidence.
Layer | What your team provisions | Typical owner | Evidence for review |
|---|---|---|---|
Network | Load balancer, firewall rules, DNS, TLS certificates | Network engineering | Diagram of allowed paths |
Identity and secrets | Key storage, rotation schedule, privileged access rules | Security engineering | Key inventory |
Data handling | Encryption, file storage, retention rules | Data and privacy | Signed retention policy |
Observability | Log retention, alert routing, dashboard access | Operations | Sample log trail |
Ownership | Named roles, escalation path, upgrade calendar | IT leadership | Runbook |
Layer 1: Network and Compute
Place the gateway behind a load balancer with redundant instances, so one node failure does not stop sender traffic. Open only the inbound paths senders need, and record each rule in the diagram your reviewer asks for.
The gateway also needs outbound reach to your core platform APIs, on-premises or cloud. Size compute to sender count and payload volume, and test large payloads before launch.
Stand up a test environment that mirrors production before senders onboard, so mappings are confirmed against realistic structures.
Layer 2: Identity and Secrets
Senders register in a self-service portal and receive an API key. Your team decides where those keys live, who revokes them, and how often they rotate. Keep keys in your approved secrets manager, never in deployment files. Revoke a sender's key the day that sender's contract ends.
Treat administrator access as privileged: named accounts, multi-factor sign-in, and a quarterly access review.
How Do You Handle Data, Logs, and Alerts?
Layers 3 and 4 show what happens to sensitive data after it arrives, so prepare their evidence with care.
Layer 3: Data Handling
Encrypt traffic in transit and data at rest. Gateway payloads carry PII and PHI, so apply the same classification you use for policy and claims stores.
Large payloads arrive as a file location instead of an inline body. Provision storage the gateway can read, limit access to its service account, and attach a retention rule your privacy team signs.
Keep production payloads out of test environments. Sample files shared by email or chat leave your controls, so give senders an approved upload path instead.
Layer 4: Observability
A dashboard records every request, response, and error. Decide how long those records live, where they ship for security monitoring, and who reads them each day. Decide which fields a log stores, so troubleshooting stays possible without PII sitting in log files.
Route alerts to a team that is on call. The gateway alerts when your core platform adds a mandatory field while the flow keeps running, so someone must own that notice.
Who Owns the Gateway After Go-Live?
Servers are the routine part of this checklist. Ownership needs a decision from leadership before launch.
Layer 5: Named Roles
Assign four roles before launch: a platform owner, a security reviewer, a sender-onboarding contact, and an on-call responder. Write each name into the runbook.
Senders carry part of the load. The sender's administrator reviews each AI-drafted mapping before data moves, so accountability for the mapping stays with the sender.
Upgrades and Change
Core platform upgrades change fields. Add gateway checks to your upgrade calendar, and clear mapping alerts in the same week they fire. Record the gateway version, mapping versions, and platform version in the runbook, so every change leaves a trail.
How Does Running In-House Compare With Other Routes?
The comparison below shows who carries the mapping work and the upkeep under each route.
Route | Infrastructure you own | Mapping work | Upkeep |
|---|---|---|---|
Hand-built per sender | One service per sender | Written by your engineers | Every sender, every upgrade |
General-purpose gateway you configure | The gateway, plus rules per sender | Written by your engineers | Rules updated by your team |
Prebuilt gateway in your environment | The five layers above | Drafted by insurance-trained AI, confirmed by a person | Alerts flag field changes |
The first two routes leave the first draft of every mapping with your engineers. The third moves that draft to software and keeps confirmation with a person. Weigh the routes against your staffing: the infrastructure column stays fixed, while mapping work and upkeep grow with every sender you add.
How InsOps Helps
InsOps builds an insurance-trained AI that assists with moving submission and claims data into your core platform. LiLa, our insurance-trained LLM, drafts the field mapping from a sender's payload to your platform's structure, and a person confirms every mapping before data moves.
The InsOps Integration Gateway gives MGAs, TPAs, brokers, and underwriting vendors a prebuilt route into your policy, claims, and billing systems. Senders register in a self-service portal, bring their payload, and configure it without building their own connector. The gateway runs inside your own environment, so PII and PHI stay in controlled infrastructure.
Each portal step lines up with a layer above. Registration and API keys touch identity, JSON validation and the mapping editor touch data handling, and the request dashboard feeds observability. The gateway flags incomplete data before it reaches an underwriter or adjuster, so gaps return to the sender instead of your queue.
InsOps is a Guidewire technology partner with prebuilt connectors to the core platforms carriers run. If you are evaluating how to exchange submission data with your core platform without a custom connector build, contact us to talk through what this looks like for your operation.
Frequently Asked Questions
What is an integration gateway?
It is the secured front door for outside data. Senders such as MGAs and TPAs submit payloads to it, and it validates and routes them into your core platform.
Why run an integration gateway inside your own environment?
Payloads carry PII and PHI, and an in-house gateway keeps that data under your own controls, logs, and review. Your security team inspects every path directly instead of relying on a vendor's assurance.
What infrastructure does a carrier need to run one in-house?
Five layers: network and compute, identity and secrets, data handling, observability, and ownership. Each layer needs a named owner and one piece of evidence for security review.
Which layer needs the earliest decision?
Ownership. Provisioning servers is routine work, but naming who reviews alerts, who revokes keys, and who handles core platform upgrades takes a decision from leadership.
What should a carrier measure to confirm the gateway is healthy?
Track request success rate, error rate by sender, the time from sender submission to arrival in your core platform, and the count of incomplete payloads returned to senders. Review open mapping alerts weekly.
How does the InsOps Integration Gateway help?
It gives senders a self-service portal and a prebuilt route into your core platform, with LiLa drafting each field mapping. A person at the sender reviews and confirms every mapping before data moves.
What does a realistic readiness timeline look like?
It depends on which layers you already run. Existing patterns for network, secrets, and logging carry over, so start the security review evidence first and assign ownership early, because an unowned layer blocks sign-off.