Operating models
Customer-managed, co-managed, fully-managed. Same product, three relationship modes, the boundary in code.
WASViking® ships three operating models that map to how partner-customer relationships actually work. The model is declared per customer access and enforced in code at every view.
The three models
| Model | Posture visibility to partner | Best for |
|---|---|---|
| Customer-managed | None. Partner sees commercial state only. | Resellers without a security operations team. |
| Co-managed | Findings, inventory, SBOM, posture. Customer keeps ownership. | MSSPs supporting an internal security team. |
| Fully managed | Full posture. Customer access is read-only or off. | Full-service MSSP delivery with no internal security operator. |
What "commercial state only" means
In a customer-managed access, the partner sees:
- Plan, billing cycle, subscription status.
- Renewal date.
- Usage and metering against the plan.
- Add-ons configured.
- Trial state and conversion windows.
The partner does NOT see:
- Findings, inventory, posture metrics.
- Scan history, scan reports, evidence.
- Security configuration (RBAC, SAML, API keys).
- The customer's audit log.
This is the right model when the partner is purely a commercial seller and security operations stay with the end customer.
Where the enforcement lives
The boundary is enforced in org_link.partner_posture_visible(access):
def partner_posture_visible(access) -> bool:
return access.operating_model != "customer_managed"
Every customer-detail view and every dashboard widget calls this gate before rendering posture data. Aggregate posture metrics in the partner dashboard explicitly exclude customer-managed accesses from the sum, so a partner with 10 co-managed customers and 50 customer- managed customers does not see false aggregate numbers.
Setting the model
The operating model is set at quote time and is part of the provisioned access. To change it:
- Open the customer detail page.
- Operating model → Change.
- Pick the new model and provide a brief reason.
- Confirm.
Every change emits a PartnerAuditLog event with the old and new
model and the operator who made the change. The customer's own audit
log also reflects the change on the customer side.
Billing is decoupled
The operating model controls what the partner sees. It does NOT control billing. Billing stays consolidated to the partner regardless of the model.
This separation is deliberate. A customer-managed access can still be billed to the partner if the commercial agreement says so; the only thing the model changes is operational visibility.
Trials and operating models
POC / trial accesses default to customer-managed. The end customer must explicitly elect co-managed or fully-managed during trial setup. The reason: in a trial, the customer is evaluating both the platform and the partner relationship, and giving up posture visibility on day one is a high bar.
What "fully managed" implies operationally
When an access is fully-managed, the partner is the operating party. Practical implications:
- The partner runs the scans.
- The partner triages findings.
- The partner handles SLA windows.
- The partner produces the Compliance evidence and Posture Shares.
If the customer wants read-only access in fully-managed mode, the partner invites them as a Read-only user inside the customer's org. Their access is independent of the partner console.
Defaults
- New quote default: customer-managed.
- After conversion to paid: stays as quoted. Operator changes explicitly.
- Per-tier default: not configurable today. The choice is per-access.