Some TPAs want plan and participant data to stay inside infrastructure they control. KinetiPlan treats customer-hosted deployment as a design priority. Infrastructure, access, backups, updates, support access, monitoring and incident response are agreed and validated with each customer before any production use.
Independent TPAs hold sensitive records: participant names, Social Security numbers, compensation, account balances and money movement. Some owners and IT leads prefer, or are asked by clients, to keep that data in an environment they run, with their own identity provider, network rules, backup policy and change control.
The usual choices are hard to reconcile. Vendor-hosted software is quick to start but gives limited control over where data lives and who can reach it. Building in-house gives control but takes time and staff most practices do not have. A customer-hosted option aims to sit between the two: packaged TPA software, deployed in your environment, with responsibilities written down before go-live.
Hosting location alone does not make a deployment secure or compliant. What matters is that each control has a named owner, is tested, and has evidence behind it. That is why KinetiPlan proposes a shared-responsibility agreement for every customer-hosted deployment.
These are intended design principles described on our security and hosting page. They are not certifications or a claim that every control is implemented today.
Role-based access, strong authentication, least privilege, joiner, mover and leaver processes, and periodic access reviews. The pilot build already assigns team members roles such as consultant, analyst, reviewer and administrator.
Encryption in transit and at rest, protected secrets and keys, data minimization, and secure retention and disposal procedures agreed with your team.
Traceable financial and administrative events with meaningful timestamps. In the pilot build, ledger transactions are timestamped and discrepancies are resolved with notes.
Documented backups, tested restoration and recovery objectives agreed for your environment, with evidence that restores work.
Versioned releases, controlled schema migrations, rollback planning and customer acceptance testing before an update reaches production.
Defined support access, incident response, patch responsibilities, monitoring and escalation procedures, written into the operating agreement.
The table below is a starting point for discussion, not a fixed model. Every row is reviewed, adjusted and signed off with each customer during the pilot.
| Area | TPA (customer) | KinetiPlan | Agreed during pilot |
|---|---|---|---|
| Infrastructure | Proposed: provisions, hardens, monitors and patches servers, operating systems, databases and network. | Proposed: documents supported environment requirements and deployment steps. | Who owns each layer, and the minimum configuration to be agreed. |
| Access and identity | Proposed: manages user accounts, authentication and periodic access reviews. | Proposed: provides role-based access in the application. | Role design, authentication method and review frequency to be agreed. |
| Data and keys | Proposed: controls encryption keys, backup access, retention, exports and secure deletion. | Proposed: documents what data the application stores and how it can be exported. | Key ownership and retention rules to be agreed. |
| Backups and recovery | Proposed: runs backups and restore tests in its environment. | Proposed: advises on what must be backed up for a consistent restore. | Recovery time and recovery point objectives and test frequency to be agreed. |
| Updates and releases | Proposed: approves and schedules updates after acceptance testing. | Proposed: supplies versioned releases, migration notes and rollback guidance. | Release cadence and acceptance criteria to be agreed. |
| Support access | Proposed: approves, time-limits and logs any remote access. | Proposed: requests access only through the agreed process. | Permitted access methods and approval steps to be agreed. |
| Monitoring | Proposed: monitors infrastructure health and alerts. | Proposed: identifies application signals worth monitoring. | Alert ownership and escalation paths to be agreed. |
| Incident response | Proposed: leads triage, evidence preservation and any required notifications. | Proposed: supports investigation and remediation of application issues. | Roles, contacts and timelines to be agreed in writing. |
Responsibilities shown are proposals for discussion. Final terms are set in a written agreement with each customer.
A customer-hosted deployment is intended to run the modules in the pilot build: plan directory and sponsors, participant census, payroll intake with census validation, the pooled trust ledger and discrepancy queue, compliance testing, the compliance calendar, annual administration projects, billing and proposals, standard reports, and a documented JSON API with interactive docs for integration work. See the 401(k) recordkeeping software for TPAs page for how these fit together, and the integration approach for how data could move in and out.
KinetiPlan is a pilot build running on synthetic demo data. It is not generally available and holds no security certifications or attestations. Customer-hosted deployment is a design priority, not a finished, packaged offering for every environment. Production hosting, security evidence and integrations are agreed and validated with each customer before live data is used. There are no live payroll or custodian connections today, and AI features are planned only. Obtain appropriate independent security and compliance review before production use.
It means the platform would run in infrastructure your organization controls, rather than in a vendor-run environment. Who handles infrastructure, access, backups, updates, support access, monitoring and incident response is agreed in writing with each customer.
No specific environment is committed to today. Supported environment requirements are defined during technical discovery and validated in the pilot.
No. KinetiPlan is a pilot build and holds no security certifications or attestations. The controls described on this page are intended design principles that must be verified before production use.
Only as agreed. The proposed model is that the TPA approves, time-limits and logs any remote support access, with the exact process set in the operating agreement.
No. Hosting location alone does not determine security or compliance. Compliance depends on how controls are owned, operated, tested and evidenced in your environment.
This page describes intended design principles. It is not a certification and not legal, tax or ERISA advice.
Discuss hosting, access controls, integrations, recovery expectations and the evidence your organization needs before a pilot, and see the pilot build in a live walkthrough.