Having just navigated the bureaucratic labyrinth of adding a freshly acquired subsidiary into our central Tugboat Logic instance, I feel compelled to document the procedure. The official docs are... optimistic. The reality involves a careful sequence of API calls, CSV uploads, and permission juggling that, if done out of order, leaves you with orphaned frameworks and very confused subsidiary auditors.
The core challenge is that Tugboat doesn't have a "Clone Company" button for this scenario. You're building a new entity from the ground up, but need to inherit controls, policies, and—critically—the parent's framework mappings. Here's the workflow that finally yielded success, after two failed attempts that required support tickets to untangle.
**Phase 1: Pre-flight in the Parent Instance**
* Export your master Control Library and Policy Library as CSV. This is your template.
* Document all active Framework mappings (e.g., SOC 2, ISO 27001, PCI-DSS) and their associated control sets. Screenshots are your friend.
* Create a dedicated user group for the subsidiary's internal team with *view-only* rights to the parent's policies and controls. This is for reference during their evidence collection.
**Phase 2: Subsidiary Instance Creation & Data Hydration**
This is where the API-first approach saves weeks. Don't click through the UI for bulk operations.
1. Use the `/companies` endpoint to create the new subsidiary entity under your main account.
2. Programmatically map the frameworks using the API. This ensures the subsidiary is assessed against the correct criteria from day one.
```json
POST /api/v1/frameworks/{frameworkId}/companies
{
"companyId": "new-subsidiary-uuid"
}
```
3. Import the Control Library CSV. **Crucial:** The 'Control ID' field must be preserved for any cross-company reporting you have downstream. Map the new "Owner" fields to subsidiary leads during import.
4. Import the Policy Library CSV, similarly mapping owners. The document links will break; you'll need a separate process for them to upload localized versions.
**Phase 3: The Integration Nightmare (Middleware Story)**
Our existing GRC dashboard pulls evidence status via Tugboat's webhooks. Adding a new company silently breaks the default configuration. You must:
* Update your webhook endpoint logic to parse the `companyId` in the event payload and route notifications accordingly.
* Reconfigure any iPaaS (Workato, Zapier) flows that monitor for control updates to include the new subsidiary's entity ID. Failure here means your dashboard will show a compliance black hole for the new entity.
**Pitfalls to Avoid:**
* **User Provisioning:** Adding subsidiary users before the control/policy import means they get bombarded with erroneous assignment emails for controls that don't yet exist in their instance.
* **Evidence Migration:** Do not attempt to bulk-migrate evidence from the parent. It creates an audit trail nightmare. The subsidiary must collect their own, but you can use the parent's evidence as a "template" document.
* **Reporting:** Consolidated reporting requires a custom view built off the API. The out-of-the-box reporting will treat the subsidiary as a completely separate tenant unless you've configured a multi-company hierarchy correctly from the start.
The entire process, once scripted, took about three business days of focused effort (mostly for validation). The "click-ops" approach was projected by support to take two to three weeks. The moral, as always, is to treat the UI as a read-only dashboard and build your integrations for any real operational workflow.
APIs are not magic.