What do organisations get wrong about personalisation in digital experiences?

Why This Matters for Security Teams

Personalisation is often framed as a user-experience feature, but security teams know it is also an identity and data-routing problem. The mistake is assuming that more context always improves the experience. More context can also increase exposure, expand consent obligations, and deepen dependency on backend identity services that were never designed for broad sharing. NIST guidance on identity and risk management makes the point implicitly: access decisions should be proportional to the need, not the appetite for data collection. See the NIST Cybersecurity Framework 2.0 for the broader governance lens.

NHI Management Group research shows how often organisations mishandle the mechanics behind these experiences: 96% store secrets outside secrets managers in vulnerable locations, and only 5.7% have full visibility into their service accounts, according to the Ultimate Guide to NHIs by NHI Mgmt Group. That matters because personalisation usually depends on service accounts, tokens, and API keys working quietly in the background. When those credentials are weakly governed, the “personalised” feature becomes a hidden trust chain that is hard to audit and easy to over-extend. In practice, many security teams discover the risk only after a recommendation engine, customer portal, or partner integration has already exposed more context than intended.

How It Works in Practice

Effective personalisation starts with bounded identity signals, not maximal data collection. The design question is not “what else can be known about this user?” but “what is the minimum context needed to produce the experience safely?” That usually means separating authentication from enrichment, and limiting enrichment to specific, documented use cases. A mature approach uses policy-driven data access, short-lived tokens, and explicit purpose binding so that the same identity proof is not reused for unrelated downstream calls.

Security teams should treat the personalisation pipeline as a chain of controlled decisions:

• Collect only the signals required for the feature, such as locale, prior consent, or account tier.
• Use backend service identities with narrow scopes to fetch profile data or preferences.
• Apply consent and retention rules before any data reaches ranking, recommendation, or segmentation systems.
• Log which signals influenced the response so the logic is explainable during review.

This is where NHI governance becomes practical. Personalisation services often rely on API keys, service accounts, and machine-to-machine access, so lifecycle controls matter as much as front-end privacy notices. The CI/CD pipeline exploitation case study is a reminder that the weakest point is often the automation layer that assembles and deploys the feature, not the user interface itself. For implementation guidance, teams can map this to identity-centered controls in the NIST Cybersecurity Framework 2.0 and then enforce least privilege on the backend services that support the experience. These controls tend to break down when personalisation is wired into multiple third-party tools because each integration creates a new, poorly documented path for identity data.

Common Variations and Edge Cases

Tighter personalisation often increases operational overhead, requiring organisations to balance relevance against privacy, performance, and support burden. The hardest edge cases are high-trust environments such as healthcare, financial services, and B2B partner portals, where a small amount of extra context can be useful but can also become sensitive very quickly. Current guidance suggests using tiered personalisation: basic, low-risk signals by default, and richer context only when the user has clearly opted in or the use case is operationally necessary.

There is no universal standard for this yet, especially when AI-driven ranking or recommendation systems infer attributes that were never directly collected. That creates a governance gap: a team may believe it is personalising based on “account history,” while the model is actually amplifying behavioural inferences that should have been treated as new sensitive data. In those cases, explainability and consent language need to match the actual data path, not the business story.

NHIMG research shows why this restraint matters: 79% of organisations have experienced secrets leaks, and 97% of NHIs carry excessive privileges, which means the supporting identity layer is often broader than the feature truly requires, as noted in the Ultimate Guide to NHIs. The practical answer is to keep personalisation reversible, auditable, and small in scope. If the feature cannot be explained in one sentence without referencing hidden backend dependencies, it is probably over-personalised.

Related resources from NHI Mgmt Group

• What do organisations get wrong about digital agreement automation?
• What should organisations get wrong about using digital wallets for onboarding?
• What do organisations get wrong about digital tenant verification?
• What do organisations get wrong about segregation of duties in federated environments?