Notes on access governance & data work

SailPoint doesn't publish list pricing — every deal is custom-negotiated — but third-party procurement data and customer reports put smaller deployments at roughly $75,000 a year, with mid-market organizations commonly landing between $100,000 and $500,000 annually. That's before professional services, which frequently add another two to three times the software cost on top, and before the dedicated admin headcount most IdentityIQ deployments end up needing to keep the platform tuned. Rollouts are typically measured in months, not days. It's built for large, regulated enterprises running continuous governance across thousands of identities and hundreds of integrated applications, and it's priced and staffed accordingly.

Okta bundles access governance into its Essentials Suite, published at $17 per user per month — call it roughly $20,400 a year for a 100-person company — with Professional and Enterprise tiers requiring a custom quote from sales. Zluri's core SaaS management and access-review platform is typically quoted in the $4–8 per user per month range depending on tier, though exact pricing for your org size still runs through a sales conversation. Both are genuinely good products for what they do: continuous, always-on visibility with live directory connectors, ongoing per-seat billing that scales as your headcount does, and dozens to hundreds of pre-built app integrations. That ongoing coverage is exactly what you're paying the subscription for.

Scimly Guard is a different shape of product on purpose. It's a one-time purchase — Base Edition at $250, the Google Workspace or Microsoft Entra ID live-connector editions at $450 each, Full Suite at $999 — not a subscription, and there's no per-seat math: whether you're reviewing 40 accounts or 4,000, the price is the same, because you're buying a tool, not renting ongoing access. It runs entirely on your own device, so there's no admin headcount required to operate it and nothing to keep "tuned." The honest trade-off: it's built for point-in-time and periodic reviews, not continuous real-time governance across a large integrated app ecosystem. If you need always-on enforcement across hundreds of connected SaaS tools, an enterprise IGA platform is the right category. If you need a rigorous, repeatable review a few times a year — or you're a consultant running these for multiple clients — Scimly Guard gets you the same rigor without a five- or six-figure annual line item.

The reviews that fall apart are almost always the ones designed as a project instead of a habit — someone decides "we should really do an access review," blocks out a week, and treats it as a one-off initiative. It gets done once, thoroughly, and then never again, because nothing about how it happened makes it easy to repeat. The reviews that stick are the opposite: intentionally small in scope per cycle, run on a fixed calendar date regardless of how busy that quarter is, with the same export, the same checks, and the same report format every time so there's no re-deriving the process from scratch.

The habit needs three things to survive without dedicated headcount: a calendar reminder that isn't dependent on anyone remembering, a repeatable ten-minute export step from each directory you're checking, and a tool that turns that export into findings and a prioritized action list without requiring a security background to interpret. Take any one of those away and the review quietly stops happening around the third quarter, usually right when a genuinely stale admin account has had the most time to sit unnoticed.

That exemption is exactly backwards. A break-glass account combines the two riskiest properties an account can have: standing, unrevocable, top-tier privilege, and — because it's used so rarely by design — almost no one watching whether it's actually still needed, still correctly scoped, or still only known to the people who are supposed to know it. An account that's used constantly gets noticed if something's wrong with it. An account that's used once every two years doesn't, which is precisely the profile that makes it valuable to leave alone if you're an attacker who's found it.

Reviewing break-glass access doesn't mean using it, which defeats the point of keeping it in reserve. It means checking three things on a fixed schedule regardless of activity: who currently knows the credentials and whether that list has grown past the people who genuinely need it, whether the account's privilege level still matches what an actual emergency would require rather than what convenience crept it up to, and whether the last credential rotation postdates everyone who's left the company since. None of that requires the account to be logged into — it requires someone to actually look at it instead of waving it through as an exception every cycle.

When you load a CSV, the app reads it directly into memory on your machine using the same File API a browser would — there's no upload step, because there's no server endpoint the file is being sent to. Parsing, scoring, and report generation all happen in that same app window, using JavaScript running locally, and the resulting PDF, Markdown, and CSV exports are assembled and offered as a local download the same way. At no point does your user data leave the device it's already on, because the application was never built with a destination for it to go to.

The live directory editions work differently but land in the same place: Google Workspace and Microsoft Entra ID connections use OAuth with PKCE, a flow specifically designed so the access token lives only in your local app session and is never exposed to, or routed through, a third-party server — including ours. The directory API calls go straight from your device to Google's or Microsoft's own APIs. We simply never sit in that path. This is also exactly why the base editions can't offer things like saved history across devices or multi-user collaboration out of the box — there's no server retaining state between sessions. That's the trade we made deliberately, and it's the same reason there's nothing on our end for a breach to expose.

The acquired company's directory almost always carries baggage the acquiring company doesn't know about yet: former employees who were suspended rather than deprovisioned, contractors from three years ago whose accounts were never fully closed out, and admin-level access handed out generously during a smaller, more informal phase of the company's life. None of that shows up on an org chart. It shows up when someone finally exports both directories and cross-references them, usually months after the deal closed and well past the point where anyone remembers why a given account has the access it does.

The practical fix is treating directory consolidation as its own access review, run before the two systems are merged rather than after — audit each directory independently first, resolve duplicate identities and stale accounts on both sides, and only then integrate. Merging first and cleaning up later means you're now running a single review against a directory that's twice the size and has inherited every unresolved issue from both companies at once, which is a much harder problem to untangle than two smaller, separate ones.

Start well before the audit window opens, not during it. You want at least one full review cycle completed, documented, and dated before an auditor ever asks for evidence — a single review run the week the audit starts looks exactly like what it is, a rush job assembled for the audit rather than an operating control. Auditors are specifically trained to spot the difference between a policy that exists and a policy that's actually been followed over time.

The minimum checklist for a first review: export user lists from every system that touches sensitive data or has admin-level roles, flag every account with no login in the last 90 days, confirm MFA enrollment status on every privileged account specifically, and produce a dated report showing what was checked and what was found — even if the answer to "what was found" is "nothing." That last part matters more than it sounds like it should: a report showing you looked and found no issues is real evidence; no report at all is a gap, regardless of how clean your access actually is.

A live connector is the right call when you want the most current possible data with zero manual export steps, when you're running reviews frequently enough that re-exporting a CSV every time becomes real friction, or when you're a consultant who needs read access to a client's directory without them having to hand you a data file at all. The trade-off is that it requires OAuth setup on the client's side and only works for the specific platforms it connects to.

CSV is the right call more often than people assume: when you're consolidating data from a system that doesn't have a live connector edition yet, when you specifically want a frozen point-in-time snapshot for audit evidence rather than live data that could change mid-review, or when IT policy restricts granting any new OAuth app access to the directory — which is a completely reasonable policy, and one a CSV export sidesteps entirely since nothing new is being authorized. Most teams end up using both: CSV for the audit-evidence review that needs a fixed snapshot, live connectors for the faster day-to-day spot-checks in between.

Start with accountEnabled and signInActivity.lastSignInDateTime together, the same pairing logic as any dormancy check: a disabled account is usually fine, but an enabled account with no recent sign-in — especially one holding a privileged directory role — is exactly the pattern worth flagging first. Cross-reference both against the account's assigned directory roles specifically, since Entra ID often shows role assignments as a separate object from the base user record, easy to miss if you're only scanning the primary export.

The field that trips people up most is onPremisesSyncEnabled. An account showing false when your organization is supposed to be running hybrid identity with on-prem AD sync usually means the account was created directly in the cloud, outside your normal provisioning path — the Entra ID equivalent of the missing SCIM external ID we've written about before, and worth treating with the same suspicion. Guest accounts (userType: Guest) deserve their own pass entirely: they're frequently added for a single project and never cleaned up once it ends, sitting with whatever access they were given at the time indefinitely.

Near-duplicates matter because they split one person's access footprint across two records that no automated process treats as the same person. Deprovisioning tooling that correctly disables jsmith@company.com when someone leaves has no idea j.smith@company.com exists, so that second account — often created accidentally during onboarding, or left over from before a naming convention was standardized — just keeps working after the person is gone. It's not malicious, and it's rarely even noticed by the person who has it; it's simply invisible to whatever system is supposed to be tracking "does this employee still work here."

Catching these requires fuzzy matching, not exact matching — normalizing for punctuation, common nickname variants, and old domain aliases before comparing records, then flagging near-matches for a human to confirm rather than auto-merging them, since some near-duplicates really are two different people. It's one of the more tedious parts of a thorough review, and one of the easiest to skip under time pressure, which is exactly why it's worth automating rather than eyeballing a spreadsheet for it.

A contractor's access is typically granted directly by whoever brought them on — an engineering manager, a marketing lead — outside the standard employee provisioning flow, and it ends the same informal way: the contract quietly finishes, the person stops logging in, and nobody sends the equivalent of a termination notice because there technically wasn't one. The account isn't revoked; it's just abandoned, functional and unwatched, which from a risk standpoint is worse than a normal dormant account because it was often given broader access than a typical employee role to begin with, for the scope of whatever project it was brought on for.

The fix isn't extending the HR offboarding trigger to contractors, since most organizations don't track contractor engagements in HR systems at all. It's treating every contractor and vendor account as inherently temporary at the point of creation — assigning it an explicit end date up front, even a rough one, so an access review has something concrete to check it against instead of relying on someone remembering to flag it manually when the engagement quietly ends.

The score starts from five weighted categories: stale/dormant accounts, MFA coverage on privileged roles, SCIM/provisioning gaps, orphaned or misconfigured records, and license waste. Each category is scored independently against your dataset, then combined using fixed weights we chose deliberately — MFA gaps on admin accounts count for more than a duplicate email, because the blast radius of a compromised, unprotected admin account is categorically different from a data-hygiene issue. None of the weighting is dynamically "tuned" per customer; the same rubric applies to a 50-person startup and a 5,000-person enterprise, because a stale admin account is exactly as risky regardless of company size.

A 100 doesn't mean "no findings" — it means no findings serious enough to move the needle at the thresholds you've set (dormancy days, cost-per-seat, and so on). This is why the report leads with a phased action plan — Immediate / This Week / This Month / This Quarter — rather than the score alone: the score tells you where you stand, the plan tells you what to actually do about it. We built it this way after watching people stare at a "68/100" with no idea whether that's actually bad or just normal for their org size. The plan removes that ambiguity.

The externalId is the unique identifier that links a user's account in a service provider (like your app) back to their identity in an IdP like Okta, Azure AD, or Google Workspace. When an account is created via SCIM, this ID is automatically populated. If it's missing, it almost always means the account was created manually — outside of your standard, automated process.

This "shadow IT" account won't be deprovisioned when the user leaves the company, because the IdP doesn't know it exists. It won't be included in automated access reviews. It's a ghost in the machine, and during a SOC 2 or ISO 27001 audit, these are exactly the kinds of discrepancies that lead to findings. Scimly Guard flags these immediately, giving you a chance to remediate them before they become an audit headache.

When you run an analysis in Scimly Guard, your user data is never uploaded to a server we control. It's processed locally, on your machine. This means there is zero risk of a data breach on our end exposing your sensitive information. For access governance, where you're dealing with employee lists, roles, and permissions, that's not a small thing.

This constraint forces us to build simpler, more robust tools. It also means the base editions can't support multi-user collaboration or saved state out of the box. We think that's the right trade-off. For teams that need more, the architecture is designed to be extended with your own backend or database, keeping you in control.

This isn't a budgeting failure; it's a provisioning one. When an employee leaves or changes roles, their access to major platforms is usually revoked automatically via SSO. But smaller, manually-provisioned tools are often forgotten. The license remains active, the credit card keeps getting charged, and nobody notices until the next annual audit.

Scimly Guard's license waste analysis flags these accounts by combining last-login dates with per-seat cost data. It gives you an exact dollar amount for monthly and annualized waste, making it easy to justify the cleanup effort and demonstrate immediate ROI to finance.

SSO (Single Sign-On) answers "who is this person, and can they log in?" It's an authentication protocol — SAML or OIDC — that lets a user log into an app using their identity provider's credentials instead of a separate password. SCIM (System for Cross-domain Identity Management) answers a completely different question: "does this account exist, and is it correctly provisioned and deprovisioned?" It's a protocol for automatically creating, updating, and — critically — removing user accounts in downstream apps when something changes in the IdP.

Here's where it breaks in practice: plenty of apps support SSO login without supporting SCIM provisioning. That means someone can be manually added to an app by an admin clicking "invite user," then log into it via SSO perfectly fine — the login flow works — while the account itself was never provisioned through, and will never be deprovisioned by, your IdP. When that employee leaves, IT revokes their IdP account and assumes access is gone everywhere. It isn't. The orphaned account sits there, fully functional, invisible to any process that only checks the IdP's user list. This is exactly the gap Scimly Guard's SCIM external ID check is built to catch.

Start with lastLoginTime and the 2-Step Verification enrollment flag together, not separately. A user who logged in recently but isn't enrolled in 2SV is an active, unprotected account — arguably higher priority than a dormant one, since it's actually being used. Cross-reference this against admin and delegated-admin status: any privileged account without 2SV enrollment should be treated as a same-day fix, not a backlog item.

The org unit path is where stale provisioning hides. Departed contractors and former employees frequently get "suspended" instead of fully deleted, and suspended accounts often sit in whatever org unit they were last active in rather than a dedicated "offboarded" unit — meaning a quick visual scan of org units won't surface them. What will: cross-referencing suspended status against a last-login date older than your policy threshold, and checking whether those accounts still hold any delegated admin roles or shared drive ownership, since suspension doesn't automatically strip either.

The right threshold depends entirely on how the role is supposed to be used. A 90-day window makes sense for a general employee account — nobody should go three months without touching their email or core apps. It makes no sense for a break-glass admin account, a seasonal-contractor role, or an account tied to an annual compliance task; flagging those as "stale" every quarter just trains your team to ignore the alert, which defeats the entire purpose of monitoring.

A better approach is tiering thresholds by role rather than applying one number company-wide: 30 days for standard employee accounts, 14 days for privileged and admin accounts, since the cost of a compromised admin credential sitting unnoticed is so much higher, and a manually-tagged "exempt, with review date" category for legitimate low-frequency accounts, so they're still checked periodically without triggering noise every cycle. Scimly Guard's CSV editions let you set this threshold per analysis run specifically so you're not stuck with a single number that's wrong for half your organization.

This is the difference between a "policy" control and an "operating effectiveness" control. Having a written offboarding checklist proves intent. Producing a timestamped log showing that a departed user's access to thirty different systems was revoked within, say, 24 hours of their termination date — for every termination in the last 12 months, not just the ones that went smoothly — proves the control actually operated as designed. Auditors sample; if even one terminated employee's account is found still active during that sample, it can turn into a documented exception on your report, regardless of how good your policy document reads.

This is exactly why manual, spreadsheet-based access reviews struggle here — the "proof" tends to be scattered across ticketing systems, Slack threads, and someone's memory of "yeah, I definitely turned that off." A generated access-review report with a clear timestamp, a list of what was checked, and what was flagged gives you something concrete to hand the auditor for each review cycle, rather than reconstructing the story after the fact when the audit request lands.

Shared accounts break the entire premise of an access review, because the review assumes a one-to-one mapping between an account and a person. When five people share one login, you can't answer "did this person's access get revoked when they left" — the account persists regardless of who's still on the team, because the login itself was never tied to any individual's employment status in the first place.

The fix isn't necessarily eliminating every shared account — some tools genuinely only support one login per organization. It's tracking them as a distinct category in your access inventory, with an explicit owner responsible for rotating the password whenever anyone with knowledge of it leaves, and a hard rule that no shared account should have standing admin or financial permissions. When Scimly Guard flags a duplicate email address across two user records, it's often catching exactly this pattern — one shared inbox provisioned into multiple tools under slightly different account names.

A checklist is a manual process, and manual processes fail exactly when they're under the most pressure to succeed — during a messy termination, a resignation with two weeks' notice that turns into two days, a role that touches forty different tools nobody fully inventoried. The checklist assumes someone remembers every system the departing employee had access to, and has time to methodically go through each one, at the exact moment that's least likely to happen cleanly.

What actually closes the gap is verification, not process — a review that runs after offboarding is supposed to be complete and independently confirms it actually was, by checking real account data rather than trusting that the checklist got followed. This is a fundamentally different control: the checklist is what someone is supposed to do; the review is proof of what actually happened. Keep the checklist, since it's still useful as a process. Just stop treating "we have a checklist" as equivalent to "we've verified access is revoked."

At small scale, least privilege usually isn't broken by a deliberate decision to over-provision — it's broken by convenience during onboarding. It's genuinely faster to add a new hire as "Admin" in a shared tool than to figure out the minimal role that covers their actual job, especially when nobody currently working there remembers why five people have owner-level access to the analytics dashboard. Privilege accumulates by default, not by malice.

The practical version of least privilege at this size is periodic, not continuous: a standing quarterly, or even biannual, pass through your admin and owner-level roles across your core tools, asking one blunt question per account — does this specific person's current job require this specific level of access, today — and downgrading anything that doesn't. You don't need a formal access matrix to do this well; you need the discipline to actually run the pass on a schedule, and a way to see admin-role accounts across your directory in one place rather than tool by tool, which is exactly the gap a directory-wide access review closes.

Most major platforms ship MFA as opt-in by default, which means "we have MFA" often just means the feature exists in the admin console — not that every user has enabled it, and definitely not that login is blocked without it. Optional MFA gets adopted unevenly: security-conscious individuals turn it on, everyone else doesn't, and attackers don't need to compromise every account, just one without it.

True enforcement means the identity provider or app itself refuses to complete a login without a second factor — no exceptions, no "remind me later," no accounts grandfathered in from before the policy existed. Getting there requires actually auditing enrollment rates, not just policy existence: pulling the real per-user MFA enrollment status across your directory, cross-referencing it against admin and privileged roles specifically, and closing the gap for those accounts first, since an unprotected admin account is a categorically worse exposure than an unprotected standard user account.

The translation that actually works is consequence, not mechanism. Nobody outside security needs to understand what MFA is to understand: if one of these twelve passwords leaks in a breach at another company — which happens constantly, and often has nothing to do with us — someone could log into our systems with full admin rights and we wouldn't get an alert. That's the same finding, reframed around what it actually means if it goes wrong, rather than the technical control that's missing.

This is also why leading with cost tends to land better than leading with risk alone, wherever there's a real number attached — "$2,280 a year in unused licenses" is unambiguous to anyone who reads a budget, in a way that "provisioning hygiene" never will be. We built Scimly Guard's reports to lead with exactly this kind of framing on purpose: a readiness score and dollar figures up front, technical detail available if someone wants to go deeper, but never required just to understand why something matters.

A manual review under time pressure optimizes for finishing, not for thoroughness. Edge cases get skipped because chasing them down takes too long relative to the deadline. The reviewer starts pattern-matching instead of actually checking — "this looks like the last export, probably fine" — which is exactly how a genuinely risky account slips through untouched for another quarter.

The real cost shows up later, when an incident or an audit finding traces back to something a rushed manual review would have caught, and someone has to explain why it wasn't. Automating the mechanical parts — parsing the export, cross-referencing dormancy, flagging MFA gaps, calculating license waste — doesn't remove judgment from the process, it just moves the reviewer's time away from spreadsheet mechanics and toward actually deciding what to do about each finding, which is the part that was always supposed to be the point.

When multiple admins use a single "admin@company.com" account, you lose the ability to prove who performed a specific task. If a configuration is changed or a dataset is leaked, the logs only show the generic account. This makes post-incident analysis nearly impossible and immediately triggers critical findings during compliance audits (like SOC 2 or ISO 27001).

To fix this, individual admins should always use unique accounts. For emergency access, use a scoped break-glass account with automated alert notifications that trigger the moment it is accessed. Scimly Guard’s directory checks are designed specifically to flag shared credential patterns and generic admin name indicators so you can clean them up before auditors ask.

SCIM provides a common schema for representing users and groups, alongside a RESTful API structure for CRUD operations. When a user is added to your Identity Provider (like Microsoft Entra ID or Okta), a SCIM connector automatically sends a request to downstream applications to create their local accounts. When the user leaves, the same connector disables access instantly.

Despite being an industry standard, many SaaS products implement SCIM slightly differently, resulting in sync errors. Auditing these sync errors is crucial to ensure that deactivated users are actually disabled in all secondary tools. Scimly Guard includes dedicated SCIM readiness checks to trace provisioning differences across systems.

Every time you connect your primary directory to a new cloud service, you expand your threat surface. If that SaaS provider is breached, your organization’s metadata—including employee emails, roles, and status flags—could be compromised. This makes onboarding new governance tools a lengthy, high-risk process requiring vendor reviews.

By building Scimly desktop-first, we eliminate this risk. Your directory data never touches a server we operate. The app uses your local hardware for calculations, processes credentials via client-side OAuth, and stores settings locally. It gives you SaaS-level insights with none of the cloud-security overhead.

Auditing shared drives requires inspecting who has access at the drive level versus the item level. Google Admin SDK APIs let you crawl drive memberships, but they return massive JSON structures that are hard to read. An unmanaged drive with "anyone with the link can edit" permissions represents an immediate data leak risk.

Best practice is to enforce a policy that restricts shared drive creation to specific teams and requires a review of memberships every six months. Removing external collaborators who haven't active logs in the last 90 days is a quick way to shrink your data liability. Scimly Guard’s Google Workspace edition exposes these drive memberships directly.

An inactive contractor account or a forgotten testing login still represents an active credential path. If that account lacks a current human owner to notice anomalies, it can be compromised—even if MFA is enabled. Attackers often target dormant accounts because their log activity is rarely reviewed by security teams.

Security is a combination of authentication (proving who you are) and authorization (proving you should still have access). MFA solves the first; periodic access reviews solve the second. Enforcing a strict deprovisioning window is the only way to ensure that the accounts passing authentication actually belong to current employees.

A classic zombie account scenario occurs when a user leaves the company, their account is disabled in AD, but their membership in high-privilege security groups is never cleaned up. If an administrator temporarily re-enables the account for testing, or if a service account shares its credentials, that legacy access is instantly revived.

To eliminate zombie accounts, you need to implement a true lifecycle process: disable the account immediately upon offboarding, strip all group memberships within 7 days, and fully delete the account object after 30 days of inactivity. Scimly Guard’s Entra ID connector highlights these deactivated-yet-privileged accounts instantly.

The key to parsing SCIM is separating core schemas from extensions. The standard user schema (`urn:ietf:params:scim:schemas:core:2.0:User`) handles username, name, emails, and status. Enterprise extensions (`urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`) introduce department, manager, and employee numbers.

When building the import parser for Scimly Guard, we focused on flattening these schemas into flat CSV formats without losing the relations. This allows teams to inspect user mappings using standard spreadsheet tools, transforming raw JSON data into clean rows and columns that are easy to analyze.

If these credentials are checked into Git, or if a local database backup is exposed, attackers can access your company's core data. Security audits like SOC 2 require rotation policies and encryption at rest for all database settings. Credentials must be stored using secure key vaults rather than plain text configurations.

When developing Scimly Insight, we ensured database credentials added to datasources are encrypted at rest using AES-256 keys, and connection credentials are only held in memory during analysis. This prevents database security leaks, ensuring user database setups remain local and secure.

Finding this waste requires cross-referencing user list active login times against subscription costs. For example, if a team has 50 Figma licenses but 12 users haven't logged in for 90 days, reclaiming those seats results in immediate cash savings. The same applies to developer licenses and database clients.

A good practice is to run a license sweep 30 days before any major software renewal. Scimly Guard computes these financial numbers automatically, showing you an exact dollar amount of monthly and annualized waste, making it easy to justify license cleanups to finance.

PKCE (Proof Key for Code Exchange) replaces static client secrets with dynamic cryptographically-generated codes created on the fly. The app creates a verifier key, hashes it to create a challenge, and sends it to the identity provider. The provider responds with an authorization code that only the app can decrypt.

In Scimly Guard, we implemented this flow entirely on the client side using a temporary local server to capture redirect ports. This allows users to authenticate directly against their Google Admin SDK or Microsoft Graph APIs without ever exposing their directory tokens to a backend server.

If a security team deprovisions an account, but the audit system logs the event with the wrong timestamp, verifying deprovisioning within the 24-hour compliance SLA becomes a nightmare. Systems need transactional event auditing that records UTC timestamps, user metadata, and specific actions.

When auditing legacy access, keeping historic snapshots of your directory lists is essential. It lets you prove to auditors that your security postures were maintained throughout the year. Scimly Guard’s PDF reports automatically embed secure, local timestamps for this purpose.

The first gotcha is byte order marks (BOM) in UTF-8, which can crash basic string splits. The second is unescaped double quotes inside cells containing commas (e.g. addresses). The third is ragged rows, where lines contain more or fewer fields than the header row indicates.

In Scimly Guard’s analysis engine, we built a resilient parser that skips mismatched records, normalizes UTF-8 encoding variations, and reports parse diagnostics. This ensures that even raw, unformatted directory exports load successfully without crashing your analysis runs.

Contractor offboarding is frequently missed because they don't go through standard HR processes. If their manager forgets to log a termination ticket, their accounts remain active. This is why contractor access should always be bound to strict, automatic expiration dates at the directory level.

Regular reviews should explicitly partition contractor lists from main employee databases. Reviewing these lists every 30 days ensures that expired contract logins are deactivated. Scimly Guard helps you flag non-domain emails and contractor accounts to simplify this review.

We evaluated Redux Toolkit but found it required too much boilerplate code for simple layout updates. Zustand, on the other hand, uses hooks and requires zero context providers, allowing us to manage layout coordinates with minimal rendering overhead.

This ensures that dragging, resizing, and renaming widgets on the Scimly Insight canvas runs at 60 FPS on standard local devices. It keeps the UI snappy, ensuring that dashboard layouts update in real time as users interact with the visual canvas.

If you upload personal data (like names, emails, and salaries) to a third-party SaaS server, you are legally responsible for their data security. However, there is a loophole: if data is processed entirely locally on the user's device, no personal data transfer occurs, bypassing the legal compliance burden.

This is why Scimly’s local-first architecture is so valuable for legal compliance. Since directory data is processed on your device, you don't need a vendor risk assessment. It provides full compliance auditing without introducing any secondary privacy risks.