This lesson covers the SSP User Profile — the page under Getting Started → SSP User Profile on the ZIMRA Self-Service Portal (https://mytaxselfservice.zimra.co.zw) where a logged-in user maintains their own account particulars: the username, the phone number and the email address. It is a short page with outsized consequences, because those three fields are the rails on which the SSP's entire identity and recovery machinery runs: the username (or email) is the login identifier, the email is the destination for password-reset and creation links, and the phone and email carry the browser-verification codes demanded at login. A stale profile does not hurt on the day it goes stale; it hurts weeks later, at the precise moment the user is locked outside the portal and the recovery message is being delivered to a mailbox they can no longer open.

The lesson's central distinction — drilled since the Introduction to TaRMS lesson and made operational here — is user profile versus taxpayer profile. The SSP User Profile describes the human being who logs in: one person, one account, one set of contact details. The taxpayer profile, managed in the separate Taxpayer Information module, describes the legal person whose tax affairs are administered — its registered particulars, addresses, revenue heads and bank details. Changing your email on the SSP User Profile tells ZIMRA where to reach you; it does nothing to the taxpayer's registered address, and vice versa. Confusing the two pages is among the most common beginner errors in the portal, and this lesson maps exactly which life events belong to which page (the taxpayer side is treated fully in the next lesson, tarmsprofile).

Legally, the profile sits in the same derivative framework as the password (see tarmspassword): Section 5 of the Income Tax Act [Chapter 23:06] (secrecy) and Sections 53–61 (representative taxpayers and the public officer) assume each login maps to one identifiable, reachable person; Section 37A(10)–(11) makes submissions under that login legally operative. The identity fields captured at sign-up (name, national ID or passport, date of birth) were verified by ZIMRA against official records and are not casually editable in the way contact details are — a name change following marriage, or a correction of a mis-captured ID number, is an identity-record matter rather than a routine profile edit, and screen-level specifics on how the SSP handles it are flagged for verification below.

The governance payload of the lesson: treat profile currency as a standing control, not a one-off task. Every job change, phone change or mailbox migration is a same-week profile update; organisations should require corporate email addresses for staff SSP accounts, sweep profiles in the same quarterly review that audits Assignee Management grants, and remember that the profile belongs to the user — when staff leave, the organisation revokes their grants but cannot and should not commandeer their account. As the SSP's own help system was not reachable when this lesson was prepared, screen-level specifics are stated generally and flagged with verification notes.

By this point in the TaRMS Essentials course the architecture is familiar: the SSP is the public front-end of TaRMS; access begins with a personal user account created once at Sign Up (tarmssspregistration); the user logs in (tarmslogin), guards and recovers the password (tarmspassword), and "shifts" into one or more taxpayers to do substantive work. This lesson covers the maintenance page for that personal account: the SSP User Profile, found in the Getting Started module alongside the login, password and logout pages.

On its face the page is trivial — a handful of fields about one person. The reason it merits a full lesson is that those fields are load-bearing for every other mechanism the course has covered:

• The username is the unique login identifier chosen at Sign Up (the registered email also works as the identifier at login).
• The email address is the recovery anchor established in tarmspassword: password-creation links, password-reset links and (where email is the channel) browser-verification codes are all delivered there.
• The phone number is the alternative channel for browser-verification codes at login.

In other words, the profile page is where a user maintains the means by which the system reaches and re-authenticates them. Its failure mode is silent and time-shifted: nothing breaks on the day an email goes stale; the break surfaces months later as an unrecoverable account on a filing deadline. The discipline this lesson teaches is therefore anticipatory: update the profile while you can still log in, because the profile is precisely what you need to have been correct once you cannot.

A second context point: the profile is also where the SSP's one-person-one-account doctrine becomes concrete. The profile holds a person's name, their ID document, their contacts. There is no "finance department" profile, no shared inbox as a registered email (or at least there should not be — section D returns to the governance choice), and no transferring an account from a leaver to their replacement. The profile page is the personal passport of the SSP world; everything organisational happens through grants in Assignee Management, never through edits to someone's identity.

As with passwords, no statute prescribes the SSP User Profile's fields or edit rules — these are TaRMS design. The legal significance is again derivative, flowing from four directions.

Identity and attribution — Sections 53–61 and Section 37A(10)–(11)

The Income Tax Act [Chapter 23:06] fixes responsibility for entities' tax affairs on identified natural persons — the representative taxpayer provisions (Sections 53–56) and the public officer (Section 61) — and Section 37A(10)–(11) makes a submitted self-assessment return constitute the assessment. The SSP operationalises this by recording which user performed every act. That record is only as good as the profile behind it: the profile's verified identity fields (name, national ID/passport, date of birth, captured at Sign Up and checked by ZIMRA against official records) are what tie the username in an audit trail to a real, findable human being. This is why identity fields are not freely self-editable in the way contact fields are: letting a user quietly rewrite who they are would sever the attribution chain the Act's machinery depends on.

Secrecy — Section 5

Section 5 (preservation of secrecy; offences in Section 5(5)/(5a)) is the reason the profile describes one person rather than a team. Taxpayer information surfaced in an SSP session is confidential; the system's ability to police disclosure depends on knowing exactly who was in the session. A profile bearing a shared mailbox as its email quietly converts every recovery link and verification code into something multiple people can intercept — a standing breach of the design, examined in the pitfalls section.

Reachability — notices and the e-channel

ZIMRA's administrative machinery presumes it can reach the people it deals with. In the TaRMS era, system-generated correspondence is delivered through the Notifications module (and typically echoed by email), addressed either to the user personally (User-mode notifications) or to the taxpayer (Taxpayer-mode notifications) — a distinction established in tarmsintroduction. The user-addressed stream rides on the user profile's contact details. While the formal service of statutory notices (for example assessment notices under Section 51, which start the 30-day objection clock) attaches to the taxpayer's registered particulars rather than a user's profile, in practice the human who must act on a notice learns of it through the channels the user profile controls. Stale user contacts therefore degrade the taxpayer's effective notice even where formal service is unaffected.

The registration backbone — Part IIIA context

The Sign Up data behind the profile is not itself the Part IIIA taxpayer registration (Sections 25A–25E, covered in tarmssspregistration and tarmsintroduction) — a user account carries no TIN and no revenue heads. But the user account is the gateway to performing Part IIIA acts, so the profile inherits gateway importance: a user who cannot authenticate (stale contacts) cannot register, amend or file for any taxpayer they represent, while all of those taxpayers' statutory clocks — Section 25B thirty-day registration, Section 37A four-month self-assessment, Section 72 QPD dates — keep running.

What is not here

Everything about the taxpayer's particulars — registered address, business details, revenue-head registrations, bank accounts, status changes (deactivation, reactivation), and the amendment applications ZIMRA processes — belongs to the Taxpayer Information module and is governed by the registration and notification obligations treated in the next lesson (tarmsprofile). Resist the urge to look for any of it under Getting Started.

C.1 What the profile contains

The SSP User Profile carries two classes of data, set at Sign Up (tarmssspregistration):

Class	Fields	Editability
Identity data	Title, first name, middle name(s), surname, gender, date of birth, nationality, National Registration ID (residents) / passport number (non-residents)	Verified against official records at Sign Up; not routine self-service edits — changes are an identity-record matter
Account & contact data	Username, phone number, email address	Self-service editable at Getting Started → SSP User Profile

The conceptual line between the classes: identity data answers who this user is (and was proven once, at verification); contact data answers how the system reaches and re-authenticates them (and must be maintained for ever after). The page exists for the second class.

C.2 The three live fields, one by one

Username. Chosen at Sign Up, unique across the entire SSP. It is the primary login identifier; the registered email works as an alternative identifier. Because the username appears in audit context as "who did this", choose and maintain something professional and recognisable. If the SSP permits changing it, change it sparingly — colleagues, grant records and habit all attach to it.

Phone number. Carries browser-verification codes at login (tarmslogin). A changed SIM or lost handset does not block login wherever email is offered as the alternative code channel, but a profile pointing at a dead number removes one of the two recovery rails — and if the email rail is also stale, the account is support-only. Update the same week the number changes.

Email address. The single most important field in the SSP user's world — the recovery anchor (tarmspassword): password-creation links, password-reset links, verification codes and the email echoes of Notifications all land there. The standing rules: it must be a mailbox only this user controls (secrecy and attribution), it should be durable beyond the current employer where the user is an individual practitioner — or deliberately corporate where the organisation's policy requires leavers' access to die with their mailbox (the governance trade-off in section D) — and it must be updated before the old mailbox is abandoned, not after.

C.3 The update procedure

The procedure itself is short, which is exactly why it gets skipped:

1. Log in at https://mytaxselfservice.zimra.co.zw (username/email + password + browser verification if requested).
2. Open Getting Started → SSP User Profile.
3. Edit the field(s) — username, phone number, email address — and save.

Three operational notes:

• Sequence matters when changing the email. Change the profile email while the old mailbox is still accessible, then confirm you can receive a test message (or a verification prompt) at the new address before treating the change as done. If the SSP verifies a new email by sending a confirmation link to it, an inaccessible new address fails safely; but never let the old address die first.
• Pair profile changes with a password review. A natural moment for the annual rotation taught in tarmspassword — you are already on the neighbouring page.
• The change affects the user everywhere. Because one user may represent many taxpayers, a profile update propagates to the user's dealings across all of them — one of the efficiencies of the user/taxpayer split. There is nothing to update per-taxpayer for the user's own contacts.

C.4 What the profile does not do — the boundary map

The most practically useful thing this lesson can give is a clean routing table for "where do I change X?":

Life event	Correct page	Module
I changed my mobile number	SSP User Profile	Getting Started
I changed jobs / my email is dying	SSP User Profile	Getting Started
I want a different login name	SSP User Profile	Getting Started
I forgot my password	Forgot Password (login page)	Getting Started
I want to change my password	Changing the Password	Getting Started
The company moved premises	Taxpayer Profile → amendment application	Taxpayer Information
The company changed its bank account	Taxpayer Profile → amendment application	Taxpayer Information
Register/deregister a revenue head (e.g. VAT)	Taxpayer Profile → application	Taxpayer Information
Company ceases trading (status change)	Taxpayer Profile → status application	Taxpayer Information
Give my new accountant access	Assignees / Tax Agent Assignment	Assignee Management
Remove a leaver's access	Assignees	Assignee Management
My name changed (marriage) / ID was mis-captured	Identity-record change — not routine self-service	—

Note the asymmetry the table reveals: user-side changes take effect as self-service edits, while taxpayer-side changes are applications that ZIMRA processes (the Taxpayer Information module's Applications/Drafts pattern, covered next lesson). That asymmetry is principled — your phone number is your business; the registered particulars of a taxpayer are the Commissioner's business too.

C.5 The quarterly sweep

tarmscertificates and the SSP's security guidance established a quarterly review of Assignee Management (remove ex-staff, minimise permissions). Fold the user profile into the same sweep. For each SSP user the organisation relies on, confirm: the email is current and corporate-policy-compliant; the phone is current; the person can actually log in (a live test, which also surfaces password problems early per tarmspassword); and the user still needs every grant they hold. Fifteen minutes a quarter, and the deadline-day failure drill never fires.

D.1 The individual — Tafadzwa, a sole-trader electrician in Kwekwe

Tafadzwa registered on the SSP with the email he has had for a decade and his everyday mobile number, and he represents exactly one taxpayer: himself. His profile management burden is minimal but real: when he replaced a stolen handset and changed numbers in April, the same week he logged into the SSP and updated the phone field — because he remembered that login verification codes can go to the phone. Cost: two minutes. The counterfactual is the tarmspassword horror story: stale phone and a forgotten password in the September filing rush would have left him explaining himself to ZIMRA support while the Section 37A clock ran.

For individual practitioners the email-durability rule points firmly at a personal, long-lived address: Tafadzwa's account is his for life, across any number of future ventures, and should never be anchored to an employer's domain.

D.2 The SME — Chiedza, accountant at a Bulawayo manufacturing company

Chiedza is one of two submission-capable SSP users for the company (the two-user minimum from tarmspassword; the other is a director). The governance question her case raises: which email should be on her profile — personal or corporate? The trade-off is genuine:

• Corporate email (the recommendation carried from tarmssspregistration for staff acting for employers): the organisation's mail security, retention and leaver process apply; when Chiedza exits, her mailbox is disabled by IT, which automatically degrades her ability to recover the SSP account she might otherwise still use — a safety property from the company's perspective.
• The corollary Chiedza must understand: her SSP account is hers, but anchored to a mailbox she loses on exit. If she moves jobs, her correct move is to update her profile email before her last day (to her new corporate address or a personal one) — otherwise she has orphaned her own account; her new employer's access comes via fresh Assignee Management grants, not via the old company's anything.
• What the company must never do: keep using "Chiedza's login" after she leaves because the mailbox is "ours anyway". Attribution (Sections 53–61, Section 37A) and secrecy (Section 5) make that a control failure, exactly as analysed in tarmspassword pitfall 6. The company's lever is grant revocation in Assignee Management on her last day — which it controls regardless of whose mailbox anchors her account.

Worked timing illustration. The company's VAT 7 falls due on the 25th. Chiedza resigned on the 10th; IT disabled her mailbox on the 10th; her grants were not revoked, and the director — the second user — had let his own profile go stale (old phone number, personal email he stopped checking). On the 24th the director's login demands a browser verification code; the code goes to the dead channels; recovery emails follow them. The return is filed late not because anyone forgot a password, but because two profiles went stale simultaneously — the exact double-failure the quarterly sweep exists to prevent. Penalty, interest, and a compliance blemish feeding the next ITF 263 renewal, all for want of two two-minute edits.

D.3 The large corporate and the agency — profiles at scale

A group shared-services centre or a tax agency runs the same rules with more zeros. Specific disciplines at scale:

• Email policy as standard: all staff SSP accounts on corporate addresses; the joiner checklist includes SSP Sign Up (own account, corporate email) and scoped grants; the leaver checklist includes same-day grant revocation across every taxpayer the leaver could shift into — remembering that one user may hold grants on dozens of TINs, so revocation must be enumerated, not assumed.
• No role accounts: "taxteam@…" as a registered email is the anti-pattern — it makes recovery links interceptable by a rotating cast, collapsing one-person-one-account into one-mailbox-many-people. Auditors increasingly test exactly this.
• Agent personnel churn: when an agency's staff member servicing a client leaves, the client's protection is the agency's prompt grant hygiene; the client should also know (from its own quarterly sweep of Assignee Management, per tarmscertificates) precisely which human users currently hold access in its name.
• Incident linkage: any compromise response (the D.3 drill in tarmspassword) starts by confirming the profile's contact details were not altered by the attacker — a changed recovery email is the classic persistence move. Check the profile first, then rotate the password.

There is no Zimbabwean case law on SSP user-profile mechanics — no reported decision turns on a stale email, a username or a verification code, and the lesson says so plainly rather than padding. The contextual authorities are those already woven through the course: the administration-and-secrecy framework and its cases in itcadministration; the assessment/objection time-limit discipline (Nestlé Zimbabwe 20-SC-290; Barclays Bank 04-HH-162) which makes effective notice and portal access practically precious; and the clearance-bindingness principle (Sabeta 12-HH-079; Sibanda v Masanga 24-SC-090, per tarmscertificates) illustrating how little sympathy "the system was hard to use" attracts. The profile's importance is preventative, which is precisely why it generates no litigation: the cases it would feature in are the ones good hygiene prevents from arising.

1. Editing the wrong profile. Changing the SSP User Profile and believing the taxpayer's registered details were updated (or vice versa). The user page reaches you; the Taxpayer Information module reaches the taxpayer — and ZIMRA cross-checks ITF 263 applications against the taxpayer profile, so a stale taxpayer record delays clearance no matter how pristine your user profile is. Correct approach: route every change through the boundary map in C.4.

2. Letting the old mailbox die before updating the profile. The update must precede the abandonment; afterwards, recovery is support-only. Correct approach: profile update is part of the leaving/migrating checklist, not the settling-in checklist.

3. Shared or role mailboxes as the registered email. Converts personal recovery artefacts into team-readable ones; breaks Section 5/attribution design. Correct approach: one person, one mailbox, one account; organisational continuity via Assignee Management, never via shared contacts.

4. Treating the profile as set-and-forget. The failure is invisible until recovery day. Correct approach: fold a profile check (and a live login test) into the quarterly Assignee Management sweep.

5. Assuming the employer "owns" the account because it owns the mailbox. It owns neither the account nor the right to use it after the holder leaves; it owns the grants. Correct approach: revoke grants on exit; the leaver updates their own profile email before the mailbox closes.

6. Ignoring identity-field errors. A mis-captured ID number or an outdated surname is not cosmetic — identity fields are the attribution chain. Correct approach: raise the identity correction through the supported channel rather than working around it.

7. Changing the email as an attacker would. If you ever find the profile's contact details changed without your doing, treat it as an active compromise: re-secure the mailbox, correct the profile, rotate the password immediately, and review recent submissions and (taxpayer-side) bank-detail changes per the SSP security guidance.

Work through the questions one at a time. Choose an answer and it is graded immediately, with an explanation and the provision it comes from. Your progress is saved, so you can stop and resume.

• The SSP User Profile (Getting Started) holds the user's username, phone and email — the rails for login identification, verification codes and all password recovery. Maintain it while you can still log in.
• User profile ≠ taxpayer profile. You are maintained under Getting Started; the taxpayer is maintained under Taxpayer Information (next lesson, tarmsprofile) — and taxpayer-side changes are applications, not self-service edits. ZIMRA cross-checks ITF 263 against the taxpayer profile.
• Identity fields are verified and anchored (attribution: Sections 53–61, Section 37A(10)–(11); secrecy: Section 5); contact fields are living data the user must keep current. Different rules for principled reasons.
• Email durability is a deliberate choice: personal/long-lived for individual practitioners; corporate for staff acting for employers — with the corollary that movers update their profile before the old mailbox dies, and employers control access through grants, never through inherited logins.
• Sequence email changes safely: new address proven reachable before the old one is abandoned.
• Quarterly sweep = grant review + profile currency check + live login test for every relied-upon user; it is the control that defeats the double-stale failure.
• An unexplained change to your own profile's contacts is an incident, not a glitch: re-secure mailbox → fix profile → rotate password → review recent activity.
• No case law exists on profile mechanics — its importance is preventative, which is the point.

User profile vs taxpayer profile — the master comparison

	SSP User Profile	Taxpayer Profile
Describes	The human who logs in	The legal person whose tax affairs are managed
Module	Getting Started	Taxpayer Information
Created by	Sign Up (user registration)	Taxpayer registration application (TIN issued)
Key contents	Username, phone, email; verified identity data	Registered particulars, addresses, revenue heads, bank details, status
Change mechanism	Self-service edit (contact fields)	Application processed by ZIMRA
Identity anchor	National ID / passport, verified at Sign Up	TIN (successor to legacy BPN)
Feeds	Login, verification codes, password recovery, user-addressed notifications	Returns, assessments, ITF 263 cross-checks, refunds, taxpayer-addressed notifications
Plurality	One per human, for ever	One per taxpayer; one user may serve many
Covered in	This lesson; tarmssspregistration, tarmslogin, tarmspassword	tarmsprofile (next)

Lifecycle events and their profile actions

Event	Profile action	Deadline discipline
New phone/SIM	Update phone field	Same week
Job change (corporate email)	Update email before last day; employer revokes grants	Last working day
Mailbox migration	Update email before old box closes; prove new box reachable	Before closure
Quarterly review	Verify contacts + live login test (all relied-upon users)	Quarterly, with Assignee sweep
Suspected compromise	Check profile first → fix → rotate password → review activity	Immediately
Marriage/ID correction	Identity-change path, not self-service	As arising

Decision flow — routing a change to the right page

flowchart TD
 A[Something needs updating] --> B{About a person or about a taxpayer?}
 B -->|A person who logs in| C{What kind of change?}
 B -->|The taxpayer entity| D[Taxpayer Information module]
 C -->|Phone, email, username| E[Getting Started: SSP User Profile]
 C -->|Password forgotten| F[Login page: Forgot Password]
 C -->|Password known, rotating| G[Getting Started: Changing the Password]
 C -->|Name, ID, DOB| H[Identity-change path - verified process]
 C -->|Who may act for a taxpayer| I[Assignee Management: grants]
 D --> J{Particulars, revenue head, bank, status?}
 J -->|Any of these| K[Taxpayer Profile: submit application]
 K --> L[ZIMRA processes; track under Applications]
 E --> M[Save; prove new contact reachable]

Statutes & sections

• Income Tax Act [Chapter 23:06] — Section 5 (secrecy; offences Section 5(5)/(5a)): one-person-one-account and personal contact channels; Sections 25A–25E (Part IIIA registration context — the user account as gateway to taxpayer registration); Section 37A(10)–(11) (return constitutes assessment — attribution of acts under a login); Section 51 (assessment notices and the 30-day objection clock — why effective notice matters); Sections 53–56, 61 (representative taxpayers; public officer — named-person accountability); Section 72 (QPD dates that do not pause for access problems).

Case law

• None on SSP user-profile mechanics — stated honestly. Contextual: Nestlé Zimbabwe (20-SC-290), Barclays Bank (04-HH-162) on time-limit rigidity (itcadministration); Sabeta (12-HH-079), Sibanda v Masanga (24-SC-090) on clearance bindingness (tarmscertificates).

ZIMRA guidance

• Comprehensive Guide to the ZIMRA Self-Service Portal (ZIMRA External Guide) — §3.4 Profile ("In Getting Started → SSP User Profile you can update your username, phone number and email address… not the taxpayer profile, which is managed separately under Taxpayer Information"); §5 Taxpayer Information (profile/applications/requests/drafts; ITF 263 cross-check warning); §6 Assignee Management (roles, assignees, tax agent assignment); §20 Security Housekeeping (own login; quarterly assignee review; phishing caution).
• ZIMRA SSP online help, https://mytaxselfservice.zimra.co.zw/help/ssp/en/default.htm — authoritative per-page reference.

DTAs / international — none cited.