Dev.to Security 🔐 Cybersecurity 👁 0 📖 24 min read

AI Tools for Swiss SMEs: A 12-Case Account Ownership and Offboarding Test

AI Tools for Swiss SMEs: A 12-Case Team Account and Offboarding Test For a Swiss SME choosing an AI tool, a vendor comparison answers only half the decision. The other half is whether the company can reliably tell who

AI Tools for Swiss SMEs: A 12-Case Team Account and Offboarding Test

For a Swiss SME choosing an AI tool, a vendor comparison answers only half the decision. The other half is whether the company can reliably tell who owns the workspace, what company information stays under company control, and what happens when an employee changes role or leaves. A paid seat does not, by itself, prove that the account, its history, shared resources, or recovery route belongs to the employer. Before buying more seats, run the synthetic account-control test below against one low-risk workflow and one higher-risk workflow. It turns tool selection into a practical acceptance decision: can the team provision, govern, review, recover, and revoke access without relying on a departing person’s personal account?

The existing IAPME Suisse comparison of AI tools for KMU compares tool categories, integrations, language needs, and data questions. This article adds a narrower operational layer: team identity, ownership, evidence, and offboarding. Keep tool comparisons as discovery aids; use the acceptance test here to decide whether a particular account setup is actually controllable.

Decision in one sentence: approve a work AI account only when a named company owner can administer it, access is assigned to named people, the applicable data and retention terms are understood, critical work can be handed over, and a leaver’s access can be revoked and verified. If any of those points depends on an employee’s private login, stop before putting company-confidential or personal information into that workflow. The test does not declare a provider compliant or non-compliant. It reveals whether your organisation can operate the account it intends to use.

What is different about this problem?

Many current “AI tools for SMEs” guides compare model quality, features, integrations, pricing, hosting, and broad privacy settings. Those are necessary questions. A team can nevertheless choose a plausible plan and still create a fragile setup: one founder creates the workspace under a personal email; a contractor owns the only recovery phone; two employees share one login; prompts and files remain in personal histories; the invoice goes to the company but administrator access does not. The failure becomes visible only when a person is absent, loses a device, changes employer, or disputes what data was submitted.

This is a lifecycle problem. Identity is created, granted, reviewed, changed, suspended, recovered, and removed. It is distinct from deciding whether an AI answer is accurate, whether a specific file may be uploaded, or whether an autonomous agent should act. The core acceptance question is: can the SME prove who has access and regain control without asking a former user to cooperate? The answer should be observable in settings, records, a contract, a test account, or a documented support procedure—not merely in a sales demonstration.

The Federal Data Protection and Information Commissioner’s employer guidance explains that private employers remain responsible for workplace personal-data processing and that processing must be proportionate to its purpose. This article turns that broad responsibility into a technical and administrative control exercise; it is not a legal interpretation of any specific vendor plan. The Swiss Federal National Cyber Security Centre’s AI workplace guidance also recommends checking entered information and preferring an organisation’s business or enterprise version where possible. “Where possible” matters: a business plan is a useful control surface, not proof that every risk has vanished.

Why the question is timely, and what the numbers do not prove

The Swiss federal SME Portal reported on 5 November 2025 that, in AXA’s annual labour-market study, the share of surveyed SMEs with clear rules about what employees may enter into AI tools was 34% overall and 23% among firms with fewer than ten employees. The portal also reported AI use rising from 22% to 34% between 2024 and 2025. Those are survey results as reported by the portal, not a census of all Swiss businesses and not evidence that a particular SME has a control failure. They do show why small firms may benefit from a lightweight, practical test rather than a lengthy governance programme. Source and study attribution.

The ZHAW AI Barometer Study 2025 provides a different lens. Its university summary describes a quantitative online survey of 137 Swiss professionals and managers; the related news release says 43% of respondents used generative AI daily in a professional context, while 20% considered it secure and 21% trustworthy. The sample is not a representative census of all SMEs: respondents came from varied company sizes and functions, and the study involved research partners. Its value here is not a precise estimate of SME account ownership; it is a reminder that familiarity and perceived security are separate questions. ZHAW study record and ZHAW summary.

A separate July 2026 SECO SME Portal article summarized an EY survey of 604 employees and said 29% of respondents were allowed to use AI through personal accounts. That question and population differ from AXA’s question about clear input rules, so the percentages must not be combined or treated as a trend. They point to a practical ambiguity: “permitted” does not tell us whether a personal account is approved for confidential work, whether the company can recover its history, or whether the employee can export it at departure. Survey summary. The gap is operational, not a claim that personal accounts are always unlawful.

Search intent and existing coverage

This article was selected against a specific Search Console query, “AI Tools für KMU,” associated with the indexable IAPME Suisse tools page. In the captured reporting window for 17–24 October 2026, that query showed 19 impressions and an average position of 13, with no recorded clicks in the checked snapshot. Search Console is a delayed, sampled reporting interface, and a short window with low impressions can move substantially. This is a prioritisation signal, not proof of market demand or a prediction that this article will rank. The chosen decision is adjacent to the query but narrower: once an SME has shortlisted a tool, can it control the team account?

A manual baseline review of visible results found many feature matrices: categories, integrations, language support, price, data-location claims, and broad privacy checks. Those pages can help build a shortlist. The additional gap addressed here is a repeatable test for identity and offboarding across the whole account lifecycle. The AXA and EY survey summaries identify policy or personal-account use as relevant issues, while the NCSC recommends organisational business accounts where possible. None of these sources supplies a ready-to-run small-team test that exercises invite, role change, recovery, and leaver access. The matrix below is that original asset.

We also reviewed the NCSC’s linked explanatory video about deepfakes and CEO fraud. The page frames it as an example of how publicly available information and AI-generated impersonation can support fraud; the video is not about SaaS account lifecycle controls. The direct transcript retrieval returned no captions, so no spoken claim from the video is relied on here. That is an evidence limit, not evidence that the video says nothing useful. The NCSC’s written guidance remains the cited source for the workplace data-handling recommendations.

The 12-case acceptance test

Use a company-controlled test workspace or a low-risk trial account. Do not test by uploading real client files. The cases below are synthetic control challenges. The sample size is 12 designed scenarios, not 12 observed businesses or measured failures. We created the cases on 27 October 2026 by mapping the lifecycle states “create, assign, use, review, recover, change, revoke, retain, delete” to common SME account arrangements. No vendor product was tested, no employees were interviewed, and no production telemetry was collected. The cases are a checklist that an SME can execute against its chosen plan; they do not produce a statistical success rate.

# Scenario Pass evidence Fail signal
1 Company starts a workspace Workspace owner uses a company-controlled identity and recovery route Founder’s private email is the sole owner
2 First employee is invited Named account, least role needed, invitation recorded Shared password or unrestricted administrator role
3 Second department joins Access is separated by team or project where required All users inherit one broad shared space
4 Employee changes role Old access is removed before new access is granted Prior project files remain reachable without a reason
5 Contractor finishes work Contractor account is disabled and tokens/sessions are reviewed Access removal depends on the contractor replying
6 Employee leaves Owner can revoke sign-in and verify the result User’s personal account remains the workspace owner
7 Admin loses device A second authorised admin can recover access Recovery code or phone exists only on one person’s phone
8 Billing contact changes Company can update billing and ownership independently Subscription is paid by a personal card with no handover
9 Shared prompt or file is removed Owner can identify the shared item and apply the available deletion process No one knows where copies, links, or exports remain
10 Audit question arrives Admin can retrieve available access, admin, or activity records The team assumes logs exist but has not checked the plan
11 Provider or plan changes Export, retention, and migration steps are documented and tested on synthetic content Essential work is stranded in a user’s private history
12 Account compromise suspected Admin can suspend sessions, rotate credentials, and notify an owner There is no named incident decision-maker

A pass means the action was actually performed or a plan-specific capability was verified in current documentation; a screenshot of a menu label is weaker than a successful revocation test. Keep the record small: date, tester, account role, case, evidence location, result, owner, and due date. Never store passwords, recovery codes, access tokens, or copies of sensitive prompts in the test ledger. If the platform does not expose a control on your selected plan, write “not available” rather than guessing. That finding may change the plan choice, the data allowed, or whether the tool is appropriate at all.

Three account patterns and the decision they imply

A personal account used for work may be acceptable for an individual’s low-risk experimentation under a clear policy, but it is weak as a company system of record. The company may not control its sign-in, recovery email, history, subscription, or deletion route. It should not become the sole location for client deliverables, team prompts, or operational knowledge. If the employee leaves, the company may have no right or technical means to take over that user’s private account. Treat it as an individual workspace; do not assume a reimbursement receipt transfers control.

A company-managed individual seat usually gives a clearer joiner/leaver path: the firm controls the identity provider or email domain, can assign named seats, and may have administration or billing controls. Verify the particular provider and plan; “business” is a label, not a universal set of features. Check whether content is excluded from training by default or by setting, what retention applies, who can access workspace content, what logs are available, and whether data can be exported or deleted. A configured company identity helps, but it does not answer the terms question by itself. CISA’s Secure by Design initiative argues that cybersecurity responsibility has been placed disproportionately on consumers and small organisations, and says technology providers should take executive-level ownership of security by design. This is US federal guidance rather than a Swiss rule; for an SME, its practical implication is to ask vendors which controls are built into the product and which burdens remain with the customer. CISA Secure by Design.

A shared team or service identity can appear convenient for a small group but often obscures individual responsibility and makes revocation difficult. Avoid shared human passwords. For automation, use a distinct service identity with a named owner, minimum permissions, stored credentials, rotation and a disable procedure. BDO’s Swiss cyber-risk guidance frames the identity question directly: organisations should be able to say who or what has access, to what, and why, and whether it is still needed. That is useful consulting guidance, not a binding standard. BDO, “KI beschleunigt alles. Auch Cyberrisiken”. For an AI-enabled account that can call tools or connect to other systems, OWASP’s LLM06 guidance identifies excessive permissions and autonomy as root causes of excessive agency; it recommends limiting extensions and downstream permissions to what the task needs. That source concerns AI applications and agents, not ordinary employee accounts, but the least-privilege principle helps when the SME’s shortlist includes an agent or connected workspace. OWASP LLM06:2025.

A small-team operating model

A workable control system does not require a new committee. Assign four responsibilities, even if one person holds more than one. The business owner decides the approved purpose and what the team needs. The workspace administrator provisions and removes access. The data owner sets what information may be entered and checks contractual and retention questions with the responsible adviser when needed. The reviewer checks outputs before they are used in customer, financial, HR, or other consequential work. For a one-person firm, write down which responsibilities are external or dormant and how access is recovered if the owner is unavailable.

Use a simple access register with one row per person or service identity: name, account type, company-controlled email, role, approved use, data class, owner, start date, last review, and disable date if applicable. Keep the register in the company’s existing access-controlled records system. Avoid collecting extra employee activity just because a dashboard offers it. The FDPIC’s workplace monitoring guidance warns that monitoring should have an objective need, be proportionate, and limit access to those authorised; the purpose of this test is to validate account control, not to inspect private content or score employee productivity. FDPIC workplace monitoring. Bain’s implementation guidance for AI also treats governance roles, responsible-AI practices, and workforce engagement as part of scaling; that is consulting perspective, not a measured claim about SME account failures, and it supports assigning a clear owner rather than leaving access control to informal habit. Bain, “Five Functions Where AI Is Already Delivering”.

For public administrations in Zurich, the cantonal technical-surveillance checklist illustrates why a monitoring purpose and scope matter. It is not a rulebook for private SMEs, and this article does not transfer public-sector law to private companies. Its value as a process reference is modest: name the purpose, limit collection, decide who may access records, and set review and deletion boundaries. Canton of Zurich / SECO checklist.

Run the test in one afternoon

Step 1: Pick a contained use case. Choose a task where the team can work with synthetic or already-public material, such as drafting a neutral event description. Avoid testing with real payroll, customer, health, legal, source-code, or confidential commercial information. List the smallest set of people who need access. Define what would make the trial a success operationally: for example, the project owner can add a named user, remove that user, and recover the workspace if the primary admin is unavailable.

Step 2: Inspect the exact account and plan. Record provider, plan name, billing owner, workspace owner, sign-in method, recovery methods, admin roles, content-sharing controls, available logs, retention and deletion controls, export options, and relevant contract documents. Use the vendor’s current terms and settings rather than a comparison article’s old screenshots. The Swiss NCSC advises checking how submitted data may be used for training and using available opt-outs; the right answer depends on the contract and settings in effect for your account. NCSC workplace AI guide.

Step 3: Execute the 12 cases. Invite a test user with minimum rights. Confirm access to the intended workspace, then remove it and verify that the user cannot re-enter through an active session or shared link where the platform supports that check. Test the backup admin using a controlled procedure. For unsupported functions, record the limitation. Do not use a coworker’s real account to simulate compromise, and do not collect prompts from personal histories as proof. If the platform cannot safely support an access test in the trial plan, ask the vendor for a documented demonstration or use a separate test tenant.

Step 4: Make a release decision. A simple rule works: any failure in company ownership, identity recovery, or leaver revocation is a hard stop for confidential team work. A missing export, detailed audit log, or workspace separation may be a conditional limitation, depending on the work and the data. It can still be a no-go for a regulated, client-confidential, or business-critical workflow. Record who accepts each residual limitation and when it must be reassessed. Do not convert a checklist score into a legal-compliance label.

A worked example: the departing bookkeeper

Imagine a five-person consultancy using an AI assistant to draft internal summaries. The founder registered the workspace using a personal mail account because it was the quickest route. Staff members share links to prompt collections, and one employee has been paying for a premium tier on a private card; the business reimburses the invoice. A bookkeeper who is leaving has created several reusable prompt templates and uploaded sample customer emails over the previous months. No one has checked whether the workspace supports named seats, whether shared items remain visible after the user leaves, or whether the owner can transfer them.

A vendor comparison may rate the assistant highly and show a business option. The acceptance test reveals three separate decisions. First, who is the contractual and technical owner? Second, which content is appropriate to retain or transfer, and who has authority to decide? Third, can the business remove access without searching through private accounts? The responsible person should not assume that the company owns a personal account merely because it paid a reimbursement. Nor should they copy all historical prompts into a new workspace automatically; some may contain personal or confidential information and need review.

The least disruptive repair could be: establish a company-controlled workspace; assign individual accounts; appoint two authorised administrators; recreate only approved prompts from synthetic or public examples; document what content is not migrated; and test revocation with a temporary test user. Whether old content should be deleted, preserved, or transferred depends on contracts, business needs, legal obligations, and the facts. The test identifies where to obtain advice; it does not decide those questions.

Data handling and account ownership are related, but not interchangeable

A company-owned identity does not automatically make every prompt appropriate. A privacy-friendly plan does not automatically give the company an offboarding control. Hosting in Switzerland does not prove that the company has adequate role assignment, logs, or recovery. Conversely, a personal account does not mean that every activity is unlawful; the purpose, content, contract, and applicable rules matter. Keep these controls separate in the decision record.

The federal FDPIC says the Swiss Data Protection Act applies to AI-supported processing and stresses transparency and control over personal data. Its employer guidance also describes proportionality and information duties in workplace data processing. These are legal-source summaries, not a conclusion about one company’s facts. The NCSC’s October 2026 guidance similarly recommends checking data before submission, anonymising where appropriate, preferring the organisation’s business or enterprise version where possible, and understanding training use and opt-outs. FDPIC on AI and data protection and NCSC guidance.

The phrase “not used for training” answers only one question. Also check retention, human review, support access, workspace sharing, regional processing, deletion, backups, subprocessors, and the difference between a consumer account and a company-managed account. These details change, so keep the date and source of the plan terms in the register. If the provider cannot answer an important point, mark it unresolved and limit the data accordingly; do not infer an answer from a product tier’s name.

Minimal evidence pack

At the end of a pilot, keep a compact evidence pack in the same place as the business decision. It should contain: (1) the use case and owner; (2) provider, plan and verification date; (3) a diagram or short list showing identity and recovery ownership; (4) the twelve case results, including failures; (5) the allowed and excluded data categories; (6) links or saved copies of the current terms and relevant settings; (7) the reviewer and output boundary; (8) the decision, residual limitations, owner, and review date. Keep only evidence that is needed to support the decision and respond to a future control question.

A small firm does not need to capture every user action merely to prove that administration exists. The register can record access changes and administration evidence while excluding prompt content. If a security event requires content inspection, define a separate, authorised response procedure with an appropriate purpose, scope, and record. The FDPIC cautions that workplace monitoring can affect employee privacy and should be proportionate; a blanket “we might need to see everything” policy is a different and more intrusive control than a targeted account administration process.

BDO’s guidance recommends identifying human and non-human identities, assigning responsibility, and applying controls such as least privilege, strong authentication, access controls, logging, and lifecycle management. Translate that into only the controls your SME can actually verify: named accounts, an administrator pair, multi-factor authentication where available, a documented recovery path, a register, and a successful leaver test. Avoid claiming certification or maturity from having a spreadsheet; evidence must match the real platform and the risk of the workflow.

What to do when a case fails

A failed test is useful if it changes a decision. If the workspace owner is a private account, do not ask the employee to hand over a password. Create an organisation-controlled workspace and have the business owner approve any content migration. If the vendor offers no way to remove a user or end sessions on the plan under review, either change plan, restrict the tool to individual low-risk use, or choose a different setup. If the only backup administrator is unavailable, appoint and test another authorised owner before depending on the workspace.

If activity records are missing, first establish what the business actually needs to know. Some SMEs only need to establish who is an administrator and when access was granted or removed; others may need more detailed records because the task is consequential. Do not buy an extensive surveillance feature without defining purpose, access, retention, and employee communication. The FDPIC’s guidance on workplace monitoring is relevant precisely because “more logs” can become a privacy intrusion if the organisation collects more than necessary.

If deletion is unclear, distinguish among removing a user’s ability to sign in, removing a shared workspace item, deleting a conversation, deleting an account, and deletion from backups or retained service records. These are different actions. Ask the provider for the current process and its limits. Do not promise that an uploaded item can be recalled from model training or every system after submission unless the provider’s terms specifically support that promise. The NCSC warns that information can be difficult to retrieve after it has left the organisation; prevention and controlled entry are therefore more reliable than assuming perfect erasure later.

Failure modes that make an apparent pass misleading

The “paid seat” fallacy: a company reimburses the fee, but the account is registered to a worker’s private email. Test identity control, not payment. The single-admin fallacy: two administrators exist on paper, but the second cannot sign in or recover the workspace. Run the recovery case. The “enterprise means safe” fallacy: the team selects a plan name without checking its current settings, contract, retention, and access model. Verify the actual tenant and terms.

The screenshot fallacy: an admin console shows a user as disabled, but a still-open session or shared link continues to work. Verify what the system permits, and record any test limitation. The policy-only fallacy: a written rule says “use company accounts,” but there is no easy approved account or workflow, so staff return to personal tools. Ask staff what the approved tool fails to do and improve the sanctioned route. The TechRadar report on Harmonic’s research describes ease of access as one reason personal AI accounts may be used for work; it is a secondary report and its sample should not be treated as a Swiss SME statistic. TechRadar report, 26 May 2026.

The over-monitoring fallacy: the company responds to unknown account use by reading employee prompts or tracking every application. That can create new privacy risks and undermine trust. Start with an anonymous or non-punitive needs survey, identity management evidence, and narrowly scoped controls. The universal-retention fallacy: keeping all content forever for continuity can be as problematic as losing it. Define which work products belong in approved company records and which prompt histories should not be copied. The one-time-review fallacy: providers change product controls and terms. Record verification dates and repeat the relevant cases after a plan change, incident, or major workflow expansion.

A simple release flow

flowchart TD
  A[Choose low-risk workflow] --> B[Name owner and data boundary]
  B --> C[Verify plan, identity and terms]
  C --> D[Run 12 synthetic account cases]
  D --> E{Company owner, recovery and revocation pass?}
  E -- No --> F[Stop confidential team use; repair or choose another setup]
  E -- Yes --> G{Data, retention and sharing understood?}
  G -- No --> H[Restrict data and resolve terms]
  G -- Yes --> I[Approve bounded pilot with reviewer]
  I --> J[Record evidence and review date]
~~~

The flow deliberately separates identity gates from data gates. A technically managed workspace can still have unsuitable terms for a particular data class. A suitable data-processing arrangement can still be undermined by one shared account with no leaver process. A release decision should say what is approved, for whom, for which workflow, and with which data restrictions—not simply “AI approved.”

## A small machine-readable register

The following JSON example is a reusable starting point, not a policy template. Use fictional values in tests and store the real register only in your approved internal system. The boolean fields express whether a control was tested, not whether a vendor has legally complied. The owner field should name a role or company-managed identity, not a password or recovery secret.



```json
{
  "workspace": "example-company-ai",
  "providerPlanVerifiedOn": "2026-10-27",
  "businessOwner": "operations-lead",
  "primaryAdmin": "[email protected]",
  "backupAdmin": "[email protected]",
  "approvedPurpose": "drafting public event descriptions",
  "excludedData": ["customer records", "employee files", "credentials", "trade secrets"],
  "accessReview": {
    "lastRun": "2026-10-27",
    "scenarioCount": 12,
    "passed": 10,
    "failed": ["shared-link revocation", "backup admin recovery"],
    "decision": "conditional: no confidential data until both failures are resolved",
    "reviewOwner": "operations-lead",
    "reviewDue": "2026-11-10"
  }
}
```



The sample records ten of twelve test cases passing as an **illustrative fictional entry**, not a measured result or an acceptable threshold. A hard ownership, recovery, or revocation failure should not be hidden by a high average score. Record each case separately, assign a repair owner, and state what the team is allowed to do while a repair is pending. This prevents a green dashboard from averaging away a control that matters.

## Limits, disagreements, and when this advice fails

Survey figures do not tell us how many companies have a broken offboarding control. The AXA-based portal summary measures whether rules exist; the EY-based summary asks about employee permission to use personal accounts; ZHAW’s barometer studies professional perceptions and usage. Their definitions and populations differ. We should not average 34%, 29%, and 20%, or infer that one is the “true” rate of shadow AI. They support a bounded conclusion: AI use and organisational controls deserve attention, but this twelve-case test is an operational design, not an empirical prevalence study.

The recommendation is strongest for a team workspace that stores shared prompts, files, or ongoing work, and for an SME that needs to preserve continuity when people change roles. It is less useful for an individual using AI only for public, non-sensitive material with no shared workspace or business-critical output. In that case, a concise policy and a clear data boundary may be enough; a full account-control test could cost more than the risk reduction. A high-risk or regulated workflow may need more than this test: legal review, security architecture, vendor due diligence, a privacy impact assessment where applicable, and a more formal access review.

Company identity control also cannot guarantee that an employee never uses an unapproved personal account, that a prompt is not copied elsewhere, or that a provider deletes every copy. The objective is to reduce dependence on private accounts, make approved work easier to access, set clear input rules, and know how to respond when an account is compromised or a worker leaves. Do not turn this article into a claim that the company can take over private accounts, read personal histories, or erase data from every external system.

## Checklist for the next tool you shortlist

- [ ] The use case, business owner, reviewer, and data owner are named.
- [ ] The candidate account is company-controlled, or its individual-use limitation is explicit.
- [ ] Every team user has a named identity; no shared human password is required.
- [ ] A primary and backup administrator can access and recover the workspace.
- [ ] Billing ownership is separate from an employee’s personal card or email.
- [ ] The exact plan’s current terms, retention, training use, export, and deletion processes are checked and dated.
- [ ] The team knows what data is prohibited, allowed, or requires approval before entry.
- [ ] A leaver can be disabled and revocation verified without asking them to transfer a private login.
- [ ] Shared files, links, prompts, and service credentials have an identified owner and handover path.
- [ ] Available logs and content controls are accurately recorded; unsupported features are not assumed.
- [ ] The twelve synthetic cases have individual results, repair owners, and evidence references.
- [ ] The pilot is limited to an approved purpose and has a review date.

The short answer to “which AI tool should our Swiss SME choose?” is therefore: shortlist by task, languages, integrations, data handling, and cost as usual, but do not release a team workflow until its identity lifecycle works. A powerful model inside an account the company cannot administer is a continuity risk. A company-managed account with untested retention and data boundaries is not automatically ready either. Use a comparison to shortlist, the [SECO SME Portal](https://www.kmu.admin.ch/en/ai-gains-ground-among-swiss-smes) and FDPIC guidance to frame the Swiss context, and the 12-case test to capture what your actual workspace can do. Approve only the use case and data level you tested; leave ranking claims, legal conclusions, and vendor promises out of the release decision.

## Sources and method notes

- Search Console query snapshot: “AI Tools für KMU,” associated IAPME Suisse indexable tools page, 17–24 October 2026; 19 impressions, average position 13, no clicks in the checked snapshot. This is a short, low-volume account report, not a stable demand estimate.
- Baseline results manually reviewed on 27 October 2026: a selection of visible search results and the IAPME Suisse tool comparison page. Coverage is a practical editorial scan, not a comprehensive or reproducible market census; result ordering and page content can vary by location and time.
- Original asset: twelve synthetic account lifecycle cases, designed 27 October 2026. Scenario count n=12; no businesses, employees, or vendor products were empirically tested. “10/12” in the JSON is fictional demonstration data. No claim of measured effectiveness or failure rate is made.
- AXA/SECO figures are attributed to the cited portal’s summary of the 2025 annual labour-market study; they are reported survey values, not population counts. EY/SECO and ZHAW figures use different questions and populations and are not combined.
- NCSC video check: an official page links an explanatory deepfake/CEO-fraud video. The direct video fetch was throttled and the caption retrieval returned no transcript text, so the article uses the NCSC’s written page, not uncaptured spoken content.
- This is an operational acceptance framework for tool-account control. It does not replace provider contract review, a legal opinion, or a risk assessment tailored to the SME’s sector and data.
📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.