Foundry Academy · Customer Service Operations · Lesson 2 of 6

Identity verification and data boundaries

Apply proportionate verification and data-minimization rules before viewing, changing, or disclosing customer information.

Start the lesson

Your learning work, on this device

No signup, cloud storage, cross-device sync or verified completion. Saving is optional. This browser profile is shared with anyone who can use it; private mode, browser cleanup or storage limits may remove work. Use only fictional or non-sensitive material. Export a copy before relying on this device.

Not saved. Worksheets, answers and practice notes currently last only in this tab.

Practice markers are self-reported, never credentials.

01 · Explanation

Identity verification and data boundaries

Objective: Apply proportionate verification and data-minimization rules before viewing, changing, or disclosing customer information.

Customer service often sits next to account recovery, payments, addresses, and private records, so convenience cannot be the only design goal. Classify support actions by impact: general product guidance may need no identity check, while changing an email address, revealing account history, or redirecting a refund requires stronger assurance. Use the organization's approved authentication process and a known system of record. Do not improvise security questions from information that may be public, and never ask customers to send passwords, full payment-card numbers, or one-time authentication codes through email or chat. If the approved verification path fails, pause and use the documented recovery or fraud-review process.

Data minimization means collecting, displaying, copying, and retaining only what the case requires. Before requesting information, explain why it is needed and where the customer should provide it. Redact unnecessary sensitive values from screenshots and case notes, and avoid moving customer data into personal messaging, unapproved AI tools, or informal documents. Access should follow role and need, not curiosity. Operators must know the breach, fraud, privacy, and legal escalation contacts, because training cannot determine every regulatory requirement. When law, contractual obligations, or identity risk is unclear, record the question and refer it to authorized privacy, security, legal, or compliance personnel.

Before you begin

  • Confirm F06–F08 are available and that no approved verification policy, birth-date rule, takeover procedure, or safety script is supplied.
  • STOP. If the approved verification policy, takeover procedure, or safety script is missing or conflicts with F06–F08, record that blocker for the authorized verification-policy owner or designated safety specialist; do not claim approval or execute any identity, access, money, or safety change.

Original overview module anchor →

02 · Compare the artifacts

Supported work. Visible uncertainty.

This is a fictional, sanitized training case. All people, accounts, products, contacts, and records are fabricated; no real personal or confidential data is present, and no legal, safety, or warranty outcome is promised.

Harbor Home support recovery

Harbor Home Systems is a fictional seller of connected thermostats. A firmware update was released to 6,200 active devices on Monday. By Wednesday, support had received 184 contacts: 91 about repeated login prompts, 47 about schedules resetting, 18 about an unfamiliar error code, and 28 unrelated questions. The public service promise says customers receive a meaningful first response within four business hours, but the queue median is 7.2 hours and 36 cases have waited longer than 12 hours. The knowledge base tells agents to reset the device, yet engineering's internal notice says repeated resets can erase diagnostic logs needed for investigation. Identity verification is inconsistent: some agents request a full date of birth for low-risk preference changes, while others make account-email changes after confirming only a device nickname. One customer says a cold home creates an urgent safety concern for an elderly parent, but the agent cannot verify conditions or diagnose health risk. A team lead drafted a blanket promise that all schedules will be restored today; engineering has only reproduced the issue on one device model and has no recovery estimate. Case notes frequently say fixed or angry customer without recording observed behavior, approved steps, result, owner, or next action. Quality reviews sample only complaints and average privacy failures into the overall score. The operations manager wants agents to close every case after sending the reset article to reduce backlog. Learners must design a truthful service response, proportionate verification, disciplined diagnosis, reliable notes, de-escalation and escalation, and a quality-coaching loop. The exercise requires urgent safety concerns to be routed through approved emergency and specialist procedures without the learner diagnosing, guaranteeing restoration, or requesting unnecessary sensitive data.

Supported example — reference only

Request type
Low-risk preference change — M02-I01 (F06)
Impact
Some agents request full birth dates; the packet does not establish that this data is necessary.
Minimum data
Learner proposal — collect only the minimum approved attribute needed for the preference change.
Approved verification
Not supplied
Failure path
Learner proposal — stop the change and route unresolved verification to an authorized owner.
Accessibility/safety escalation
Offer an approved accessible verification alternative; method not supplied.
Owner
Customer-service manager and privacy reviewer
Status
Draft — policy review pending

A well-handled evidence gap

Request type
Account-email change — M02-I02 (F07)
Impact
Changing account identity after only a device nickname creates an account-takeover risk.
Minimum data
Not supplied
Approved verification
A stronger approved identity check is required, but its method is not supplied.
Failure path
Learner proposal — stop the change and escalate suspected takeover.
Accessibility/safety escalation
Accessible alternative and urgent-escalation procedure are not supplied.
Owner
Identity/security owner
Status
Blocked — approved method not supplied

Flawed approach — do not copy

Marking this six-request verification decision table “approved and complete” without the required evidence or reviewer is a flawed submission. Stop when the requested action can change identity, access, money, or safety and approved verification is absent or fails.

Repair: Rework the six-request verification decision table as an evidence-backed draft, not an approved result. List six request classes as learner-proposed categories, including preference and account-email changes. Assign impact and identity risk before choosing data collection. Use F06 to reject excessive full-birth-date collection for low-risk preferences. Check the revision against this requirement: All six request types have risk, minimum-data, failure, and escalation rules. If the required evidence is still absent, keep the decision blocked and identify the missing input or authorized reviewer.

Full case record, ambiguities and all assignments →

03 · Bounded practice

Build the six-request verification decision table.

Match verification strength and data collection to the risk of each requested action.

Deliverable: A verification decision table for six common request types.

Complete a bounded starter and gap analysis using only CB01, F06, F07, F08, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

Exact supplied inputs for this assignment
  • M02-I01 · F06 — Some agents request full birth dates for low-risk preference changes.
  • M02-I02 · F07 — Other agents change account email after verifying only a device nickname.
  • M02-I03 · F08 — One customer reports an urgent cold-home concern involving an elderly parent.
  • M02-B01 · CB01 — Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
  • M02-S01 · F06, F07, F08 — Build a starter version of “A verification decision table for six common request types.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

Operating procedure

  1. List six request classes as learner-proposed categories, including preference and account-email changes.
  2. Assign impact and identity risk before choosing data collection.
  3. Use F06 to reject excessive full-birth-date collection for low-risk preferences.
  4. Use F07 to require stronger approved verification for account-email changes.
  5. Add explicit failure, suspected-takeover, urgent/accessibility, and specialist-escalation paths.
  6. Check that methods are marked proposed and no verification is represented as completed.
Field-by-field guidance
Request type
Name the customer action and include its cited module input/fact ID when it is packet-supported.
Impact
Describe the bounded privacy, account, accessibility, or safety consequence supported by the cited fact.
Minimum data
List only information necessary for the action; label an unsupplied data rule as a learner proposal.
Approved verification
Record the approved method or Not supplied; never convert a learner proposal into policy.
Failure path
Define the proposed stop, retry, or takeover-escalation route without claiming execution.
Accessibility/safety escalation
State the reasonable-access or urgent-safety route and preserve the authorized-review boundary.
Owner
Name the role authorized to approve verification and escalation rules.
Status
Use Draft — policy review pending, Open — not supplied, or Blocked.
Six-request verification decision table · learning draft
Request typeImpactMinimum dataApproved verificationFailure pathAccessibility/safety escalationOwnerStatus

Start with 6 rows; the complete workbook specifies 6 stable rows for this artifact. Add rows here or use the full download. No action is saved until you explicitly choose saving above.

Download complete six-module workbook (.md) · Structured case packet (.json)

Keep private client data, unpublished inventions, personal identifiers and credentials out of these public learning tools.

Module 2 · 2-item formative check

Identity verification and data boundaries

Choose an answer and request feedback. Read why each option does or does not fit the evidence. Answers stay in this tab unless you choose device-only saving; they are never submitted.

Question 1 of 2 · MODULE 2 · knowledgeA customer requests a low-risk public preference change. Which verification approach is proportionate?
Question 2 of 2 · MODULE 2 · scenarioHarbor Home confirms excessive verification for low-risk changes in F06 and weak verification for email changes in F07; F08 is provisional and describes an urgent cold-home report. Which workflow sequence is appropriate?

Answer either question to review its reasoning.

Inspect the artifact, not just your quiz answers

  • All six request types have risk, minimum-data, failure, and escalation rules.
  • No row claims a verification result.
  • F06–F08 are cited where used.

Stop: Stop when the requested action can change identity, access, money, or safety and approved verification is absent or fails.

Go: Proceed only for the lowest-risk action after the approved minimum verification succeeds.

Escalate: Escalate takeover signals, accessibility barriers, and urgent safety context to the designated specialist.

04 · Evidence to keep

Leave with usable work.

Submit the completed action matrix with the risk, approved channel, prohibited data, and escalation owner for every scenario.

Download your artifact CSV and, if wanted, export the learning-work JSON above. Neither export is a reviewed submission or certificate. Device-only saving is optional; you must press Save my work now after edits.

When all six artifacts are ready, compare the full packet against the track rubric. Qualified human review is still required before real-world decisions.

Customer support professional working with a headset and laptop.
Learn the standard. Practice the work.
Office professional documenting and resolving a customer service case.
Leave with evidence you can inspect.

Sources, scope and review boundaries

Curriculum 2026.10.08-learning-paths-1. External source dates below are record checks, not continuing guarantees. Verify current requirements before consequential use.

ftc-protecting-personal-information · Official guidance

Protecting Personal Information: A Guide for Business

FTC guidance on inventorying, minimizing, securing, disposing of, and planning for incidents involving personal information.

Open reviewed external source ↗

nist-sp-800-63-4 · Official guidance

NIST SP 800-63 Revision 4 Digital Identity Guidelines

Primary NIST guidance for risk-based identity proofing, authentication, privacy, fraud prevention, and customer-experience considerations.

Open reviewed external source ↗

ws-customer-service-operating-standard · Academy internal operating standard

Wealth Synergy customer-service internal operating standard

Academy-selected service-promise, case-note, triage, escalation, knowledge, QA, and review controls. This is an internal operating standard selected by Foundry Academy; it is not law, accreditation, licensure, or an external-standard requirement.

Version 1.0 · reviewed 2026-09-01 · owner: Foundry Academy curriculum owner

A future Wealth Synergy private professional-development certificate would be issued only after its assessment, capstone, identity, reviewer, retention, access, deletion, appeal, and issuance controls pass quality review. No credential is currently issued. Any future certificate would not be an accredited academic qualification, professional license, or government certification.