Identity Iceberg Worksheet

What the Identity Iceberg Worksheet Actually Is

Most people treat the Identity Iceberg Worksheet like a self-help exercise. It's not. It's a structured mapping tool used in digital identity management, SaaS onboarding, and identity governance frameworks to separate what users present from what systems actually know about them. The concept comes from a real modeling technique that visualizes identity layers: the visible surface (name, role, login) sits above water, and everything below (attributes, clearances, behavioral signals, historical data) is hidden but critical.

I've used this framework across three different companies now, and the core value isn't philosophical. It's operational. When you map out which identity attributes are surface-level versus deep infrastructure, you stop building permission models on assumptions. Here's how I structure mine. First column: identity element. Second column: which layer it belongs to. Third: who can observe it. Fourth: how it's stored. Fifth: what happens when it changes. That fifth column kills most implementations because people skip it. I had a case where a client mapped their entire SSO identity using this worksheet and missed a single attribute change flow. When someone updated their role, the surface identity updated immediately, but the hidden clearance layer pulled from a legacy LDAP sync that ran once a day. So for 24 hours, a demoted employee still had elevated access. The worksheet caught it, but only after I forced the "what happens when it changes" column to be filled out for every single row. Took me about 45 minutes. The rest of their audit would have taken three weeks to uncover the same issue.

How to Build One Without Wasting Time

Start with your actual tech stack, not your ideal one. I've seen too many teams draft identity icebergs based on how their product should work rather than how it does. That creates a document that looks good in a meeting and fails completely during a penetration test.

Gather your user entity. Pull every attribute field from your primary database table for users. Cross-reference it against what gets exposed through your API responses. Then check your analytics and logging pipelines. Most organizations have at least three places storing identity data that never talk to each other. Here's a realistic breakdown of what typically ends up above and below the line: Above the waterline (surface identity): Username, display name, profile photo, public role, department, timezone, language preference. These are things another user might see without authentication. They're also what shows up in your UI headers and notification emails.

Below the waterline (hidden identity): Hashed passwords, MFA device IDs, IP reputation scores, device fingerprints, session tokens, audit log timestamps, role derivation logic, consent flags, data retention windows. These don't appear in any user-facing interface. They exist in databases, token stores, WAF configurations, and SIEM pipelines. The row most people forget is behavioral identity. Login patterns, typical activity windows, geographic anomalies, typing cadence, session duration norms. This lives below the surface in most systems, but it's often the thing that actually triggers a security alert. If you're building an identity program and your iceberg doesn't account for behavioral attributes, you're mapping half the structure.

Where This Method Falls Apart

The Identity Iceberg Worksheet doesn't scale well past a few hundred identity types. I tried applying it to a system with 14 different entity classes — employees, contractors, service accounts, API keys, bot identities, partner integrations, and so on. The worksheet became unmanageable around row 80. Every row needed five columns of detail, and the document turned into something nobody would actually read.

When you hit that point, switch to a matrix approach instead. Keep the iceberg concept but organize it by entity type and access level rather than as one continuous list. You lose some of the visual clarity but gain something more useful: a reference document someone might actually open when designing permissions. Another failure mode: treating this as a one-time exercise. The last time I audited a client's identity iceberg, about 60 percent of the rows were outdated within six months. Their product team shipped new features, added social login providers, changed how they stored session data. The iceberg never got updated to reflect any of it. The document existed but no longer described reality. I recommend tying updates to your release cycle — even a quarterly pass where someone goes through and verifies each row takes maybe two hours and prevents entire categories of misconfiguration.

Practical Use Cases

The main reason people build these is compliance. SOC 2, ISO 27001, GDPR impact assessments all require you to document what identity data you collect, where it lives, and who can access it. An identity iceberg covers that ground faster than writing narrative documentation.

Beyond compliance, it's useful for permission design. If you know which attributes are surface versus hidden, you can make deliberate choices about which ones influence access decisions. A user's public department shouldn't control backend resource access. Their derived clearance level should. The worksheet makes that distinction explicit instead of letting it happen by accident. I also use it when migrating identity providers. Moving from Auth0 to Okta, or from a custom solution to something like Keycloak, the iceberg tells you exactly what you need to port and what you can leave behind. Without it, migration projects tend to either over-engineer the new setup or miss edge cases that show up later under production load. The worksheet version of this process usually saves between 10 to 20 hours on a typical migration compared to going in blind. If you want a starting point, look for a spreadsheet with columns for identity element, layer classification, observer scope, storage location, and change response. Fill in your own data. The template itself is not the output. The process of filling it in is what catches the problems.