The prevailing wisdom in GRC platform administration, particularly for frameworks like SOC 2 or ISO 27001, is to spin up a separate instance for each new corporate entity or subsidiary. This, I argue, is a strategic misstep born from a failure to architect for scale from the outset. Having just completed the integration of a 150-person EMEA subsidiary into our central Sprinto instance, I find the process revealing of both the platform's capabilities and its non-obvious constraints.
Our primary driver was the need for consolidated oversight and reporting. A fragmented instance model creates audit trail discontinuity and multiplies administrative overhead. However, the "one instance" approach necessitates a meticulous, phased process to avoid polluting the parent entity's control environment. Below is the pragmatic sequence we followed, which others might find instructive.
**Phase 1: Pre-Onboarding Structural Configuration**
Before a single user is imported, the foundation must be laid. This occurs entirely within the `Organization Settings`.
* **Create a distinct `Company`.** This is Sprinto's primary segregator. It allows you to maintain separate company profiles, compliance frameworks (if needed), and most importantly, a discrete set of `Policy Groups`.
* **Architect Policy Groups with precision.** This is the critical step. We cloned our core policy groups (e.g., `Infrastructure-Security`, `Access-Management`) but prefixed all new groups with the subsidiary's codename (e.g., `EMEA-Infrastructure-Security`). This maintains logical separation while preserving template consistency.
* **Configure Integration Scopes.** For cloud services like AWS or GCP, you must pre-define which accounts or projects belong to the subsidiary. This often requires service account adjustments at the cloud provider level to ensure clean telemetry data segregation.
**Phase 2: User Import & Access Modeling**
User management is where the single-instance model is most vulnerable to error. A blanket import will incorrectly map users to the parent company's policy groups.
1. We exported the subsidiary's user list into a CSV, with a mandatory `company` column set to the new company's name as defined in Sprinto.
2. The import was performed, but **no roles were assigned** during this batch operation.
3. Roles were assigned manually in a secondary step, leveraging Sprinto's role-based access control (RBAC). We created a `Subsidiary-Auditor` role, scoped specifically to the new `Company` and its associated `Policy Groups`, preventing cross-entity data visibility.
```yaml
# Example of the CSV structure for clean import:
email,firstName,lastName,company,department
jane.doe@subsidiary.example.com,Jane,Doe,EMEA Subsidiary,Engineering
john.smith@subsidiary.example.com,John,Smith,EMEA Subsidiary,Sales
```
**Phase 3: Control Mapping & Evidence Collection**
This is the most labor-intensive phase. The subsidiary will inherit the parent's control library, but evidence must be sourced from *their* systems.
* **System Re-linking:** Each control (e.g., "MFA enforced for administrative access") required us to link the evidence source (e.g., Okta, GSuite) from the subsidiary's own tenant. The pre-configured policy groups streamlined this.
* **The Pitfall of "Common" Systems:** A significant hurdle was shared infrastructure. A single global AWS account used by both parent and subsidiary necessitates manual evidence segmentation, often through detailed Confluence or Jira documentation links, which weakens automation.
The outcome was successful, but it exposed a key limitation: Sprinto's reporting engine, while capable of filtering by `Company`, still requires careful validation to ensure subsidiary-specific exceptions or failures don't inadvertently roll up into a global "green" dashboard. The onus is on the administrator to construct these safeguards.
In conclusion, while a single-instance strategy is superior for long-term governance, it is not a click-through operation. It demands upfront design work, a disciplined adherence to naming conventions, and a deep understanding of how your evidence sources map to corporate boundaries. The alternative—multiple instances—simply defers this complexity to the auditor's review, where reconciling disparate reports becomes its own special kind of failure.
Plan for failure.
James K.