Anaplan holds your most sensitive planning data: headcount and compensation, pricing, forecasts, acquisition scenarios. The platform provides strong security controls, but most of them are configured per tenant and per model, by you. This checklist walks through the controls we review on every security engagement, in the order we review them. It supports, rather than replaces, the formal security documentation on help.anaplan.com and your own information-security policy.
1. Identity and single sign-on
- SSO enforced via SAML 2.0 with your identity provider (Entra ID, Okta, Ping). Anaplan supports SAML-based SSO at the tenant level; once enabled, users authenticate through your IdP, and your IdP's MFA and conditional-access policies apply.
- Exception users documented. Integration service accounts and break-glass admins that authenticate outside SSO should be explicitly listed, reviewed quarterly, and protected with certificate authentication where possible.
- Certificate-based authentication for integrations. Anaplan Connect and API clients should use a CA-issued certificate registered in the tenant rather than a username and password.
- Joiner/mover/leaver tied to the IdP. When someone leaves, removing them from the IdP group should remove their access. Confirm it actually does by testing with a deprovisioned test account.
2. Tenant administration
- Tenant administrators limited to a named, small group. Tenant admins can manage every workspace and user.
- Workspace administrators per workspace, not blanket. Workspace admin grants model-building rights and full data visibility inside that workspace.
- User list reviewed for dormant accounts. Anyone who has not logged in for 90 days should be removed or disabled.
- Security settings reviewed in the tenant administration console, including any access restrictions Anaplan makes available for your tenant. Confirm the settings match your policy rather than the defaults.
3. Model roles
Roles control what a user can see and do in a model: which modules, which actions, which pages.
- Role per persona, not per person. Cost Center Manager, Department Head, FP&A Analyst, Model Builder, Read Only. If you have more roles than personas, consolidate.
- Module access set to None by default, then opened per role. Review every module where a planner role has Write access and confirm it is an Inputs module.
- Action access restricted. Imports, exports, processes, and delete actions should be available only to the roles that run them. An export action available to everyone is a data-exfiltration path.
- Page access aligned with roles so users cannot reach pages for data they should not see, even if module access would block the data.
- Model builders are not planners. Workspace admin rights override role restrictions; keep the number of workspace admins small and use development models for build work where possible.
4. Selective access and dynamic cell access
Roles decide what kind of data a user sees. Selective access decides which items.
- Selective access enabled on the lists that carry organizational sensitivity (cost center, legal entity, employee, sales territory).
- Assignments maintained from a source, ideally imported from HR or the org hierarchy, not edited by hand. Hand-maintained selective access drifts within a quarter.
- Selective access reviewed against the hierarchy after every reorganization. A manager who moved departments frequently keeps access to the old one.
- Dynamic Cell Access (DCA) used for finer control: lock submitted budgets, hide compensation columns from non-HR roles, make prior periods read-only. DCA driver line items belong in a System module with clear names.
- Test as a user. Log in as a test user in each role and verify what they can see. Do not trust the configuration screen alone.
5. Data in transit and at rest
- Encryption in transit is enforced by the platform (TLS). Confirm your integration clients verify certificates and do not disable TLS checks in scripts.
- Encryption at rest is provided by Anaplan. If your policy requires customer-controlled keys, evaluate Bring Your Own Key (BYOK), Anaplan's add-on that lets you manage the encryption keys for your workspaces. Confirm with your Anaplan account team which workspaces and features are in scope for BYOK.
- Exports governed. Every export action writes data to a file. Review who can run exports and where the files go (CloudWorks to a bucket, Connect to a server, a user's laptop).
6. Integration security
- Service accounts dedicated per integration, with the minimum role and selective access needed to run their imports and exports. Never use a person's account.
- Secrets managed properly. Certificates, private keys, and any passwords in a secrets manager or vault, never in a script or a shared drive.
- Data Orchestrator and CloudWorks connections reviewed for scope: a connector with write access to your warehouse is a bigger risk than one that reads.
- Integration endpoints allow-listed at the source system where that is possible.
7. Audit and monitoring
- Audit logging in use. Anaplan's audit capability records user, security, and model events and exposes them through the API. Export it to your SIEM rather than reading it in the console.
- Alerts for high-risk events: new tenant admin, SSO setting change, new workspace admin, export actions by unusual users, out-of-hours logins from service accounts.
- Model history reviewed after any incident; model history records every structural and data change with the user who made it.
- Quarterly access review with evidence: who has which roles and selective access, signed off by the data owners.
8. Development lifecycle
- Application Lifecycle Management (ALM) in place, with a development model feeding a deployed production model. Production models in deployed mode cannot have their structure changed directly, which is as much a security control as a change control.
- Test models use masked data if they are accessible to people who should not see production numbers.
- Archived models reviewed. Old copies of a model contain old but still sensitive data and are easy to forget.
How to use this list
Run it once as a baseline and record the findings. Then fix in priority order: identity and admin scope first (sections 1 and 2), then roles and selective access (3 and 4), then integrations and audit. Most organizations find their biggest exposure in section 4, where selective access has drifted from the org chart, and in section 6, where an integration account has far more access than it uses.
If you would like a full review, including remediation, see our Anaplan Data Security Services.