ICO privacy-by-design update and NCSC passkey guidance: 2 UK SME GRC angles (2026)

Two routine reviews close a gap that often appears during buyer diligence: a product team cannot show why it collects data, and an IT team cannot explain whether its logins resist phishing. The ICO’s privacy-by-design guidance and the NCSC’s passkey guidance give SMEs a practical post angle for each.

Quick view

Brief	UK source and signal	LinkedIn angle	Action window
Privacy by design	The ICO updated its guidance on 5 February 2026 to reflect the Data (Use and Access) Act 2025, including a new duty concerning children’s higher protection matters. 1	Turn product, CRM and AI changes into recorded privacy decisions rather than a late-stage sign-off.	Use the next material change or design review as the trigger.
Passkeys	The NCSC’s 23 April 2026 publication says passkeys are a more secure, usable replacement for passwords and recommends them where services support them, with 2SV where they do not. 2	Treat phishing resistance, recovery and rollout evidence as part of authentication governance.	Use the next identity review or SaaS onboarding decision.

Brief 1: Make privacy a design checkpoint, not a launch-day scramble

Audience pain point

A small business often reviews privacy when a new product or service is nearly ready. By then, the CRM fields, analytics tags or AI feature may already be embedded in the workflow. The team has to reconstruct why each field exists instead of showing the decision as it was made.

That weakens internal accountability and makes buyer questions harder: what data is collected, for what purpose, for how long, and who can access it?

What the ICO guidance says

The ICO’s Data protection by design and by default guidance was last updated on 5 February 2026. The update reflects the Data (Use and Access) Act 2025 and adds a subsection on the children’s higher protection matters duty. That additional duty applies to online services likely to be accessed by children; it is not a blanket requirement for every SME. 1

The core requirement is broader than a privacy notice. The ICO says organisations must integrate data protection into systems, services, products and processes from the design stage and throughout the lifecycle, using appropriate technical and organisational measures. By default, the organisation should limit personal information to what is necessary for each specific purpose, including the amount collected, the extent of processing, the retention period and the degree of access. 1

The ICO’s practical starting point is to map the information, purpose and risks before processing begins. It says a DPIA is required when processing is likely to result in a high risk to people’s rights and freedoms; it also describes a DPIA as good practice more broadly. The guidance says organisations should consider the state of the art, implementation cost, the nature and purpose of processing, and the likelihood and seriousness of risks. 1

The SME translation

The useful control is a lightweight change record that another person can understand without the original project lead. For each material change, keep:

Purpose and data map. Name the business purpose, the personal information involved, the systems and processors in scope, and the data that is explicitly out of scope.
Necessity and risk decision. Record why each data element is needed, the risks to people, the measure selected, and whether the change needs a DPIA.
Default settings. Capture retention, access, visibility, deletion and user-choice settings before launch. Check that the default does not quietly collect more than the stated purpose requires.
Ownership and review. Name the decision owner, date the decision, and set a trigger for review when the purpose, supplier, model, audience or data set changes.
Evidence for the commercial conversation. Keep the data map, risk note or DPIA, access decision and processor check together. The ICO says designing for privacy can reduce later redesign costs, build user trust, and make it easier to meet procurement requirements or partner with organisations that expect strong information governance. 1

This does not mean every change needs a large compliance project. It means the business can show what it decided, why the decision was proportionate, and what would cause it to be revisited.

Brief 2: Replace password-policy theatre with a passkey rollout plan

Audience pain point

Many SMEs can point to a password policy and an MFA setting. Fewer can answer the harder questions: is the login method resistant to phishing, how are credentials recovered, which privileged accounts have migrated, and what happens when a staff member changes role?

That matters in a buyer review because “MFA enabled” describes a setting, not the strength, coverage or operating evidence of the authentication control.

What the NCSC says

In a publication dated 23 April 2026, the NCSC said it would begin recommending passkeys wherever a service supports them, and two-step verification (2SV) where it does not. The publication describes passkeys as a more usable and secure replacement for passwords; it is a policy direction and technical assessment, not a new UK legal duty or an SME certification scheme. 2

The NCSC’s assessment focused on common attacks including phishing, credential reuse and session hijacking. It says traditional MFA methods remain phishable, while FIDO2 credentials, including passkeys, are as secure or more secure than traditional MFA against the common credential attacks observed in the wild. Where user verification is required, the NCSC considers FIDO2 authentication to constitute MFA. 3

The evidence boundary matters. The NCSC says passkeys remove the ability to cheaply reuse or relay credentials, so large-scale attacks directly targeting correctly implemented passkeys are unlikely. It also says users still depend on the security of their devices and credential managers, and services need clear credential-management and recovery options. 3

The SME translation

Turn “we support MFA” into an authentication decision that has scope, exceptions and operating evidence.

Map the high-value logins. Start with administrators, remote access, finance, customer-data systems and other accounts whose compromise would interrupt a critical service.
Check the real options. For each service, record whether passkeys are supported, what user verification is required, how synchronisation is protected, and what recovery and removal paths exist.
Roll out in a controlled order. Pilot with internal administrators and a small user group before expanding. Keep an exception list for services that do not support passkeys and document the 2SV fallback.
Test the lifecycle. Retain evidence for enrolment, recovery, revocation, leavers, role changes and lost devices. A passkey policy without a recovery test is incomplete operational evidence.
Describe the control honestly. In a buyer pack, state which systems and user groups use passkeys, which remain on 2SV, and when the scope will be reviewed. Do not turn a rollout in one application into a claim about the whole business.

The growth angle is practical: a prospect does not need a slogan about “zero trust”. They need a bounded answer about which accounts are protected, how exceptions are handled and whether the business can recover access without weakening the control.

References

1
Data protection by design and by defaultico.org.uk
2
Passkeys are more secure than traditional ways to log inncsc.gov.uk
3
Passkeys are more secure than traditional ways to log in — PDFncsc.gov.uk

ICO privacy-by-design update and NCSC passkey guidance: 2 UK SME GRC angles

Quick view

Brief 1: Make privacy a design checkpoint, not a launch-day scramble

Audience pain point

What the ICO guidance says

The SME translation

Suggested LinkedIn post structure

Brief 2: Replace password-policy theatre with a passkey rollout plan

Audience pain point

What the NCSC says

The SME translation

Suggested LinkedIn post structure

References

Related content