Luxury Properties Hub · Issued to the Outsourced IT Service Provider

External IT Service
Operating Procedure

Provisioning, access control, device standards, revocation and service levels

Appendix B to SOP-HR-05 and SOP-HR-06 · Core platforms: Microsoft 365 and Bitrix24

01Service scope, operating model and authorisation channel

02Request intake, priority definitions and service levels

03Onboarding runbook — identity and Microsoft 365

04Onboarding runbook — Bitrix24 CRM and HR

05Device build standard and day-one handover

06Change, role change and access request control

07Offboarding runbook — timed revocation sequence

08Immediate revocation and security incident response

09Security baseline and technical standards

10Reporting, KPIs and service governance

11Annex 1 — naming conventions and standards

12Annex 2 — evidence templates

DocumentSOP-IT-01

Revision1.0

Client ownerHR Director

Provider ownerIT Account Manager

Service hoursMon–Sat, 09:00–18:00 GST

Out of hoursP1 incidents and revocations only

Review cycleQuarterly service review

ClassificationConfidential — provider copy

This document may be shared in full with the appointed provider. It deliberately contains no payroll, commercial or employee personal data.

SECTION 01

Service Scope and Operating Model

What the provider owns, what the client owns, and who may instruct whom

In scope

Identity lifecycle — creation, modification and revocation of every user account across Microsoft 365 and Bitrix24.
Access control — applying the Role Access Matrix exactly as issued, and refusing anything not authorised through it.
Device lifecycle — build, security baseline, deployment, support, wipe and return to stock.
Mailbox and data continuity — shared mailbox conversion, delegation, drive and document ownership transfer.
Support — incident and service request handling within the published service levels.
Assurance — provisioning evidence, revocation certificates, monthly reporting and quarterly access reconciliation.

Out of scope

Procurement, purchase approval and physical delivery of hardware or SIM cards — owned by Admin.
Deciding who should receive access — owned by the Department Head and HR Director.
Bitrix24 commercial configuration — sales pipelines, deal stages, automation rules — unless separately contracted.
Property portal contracts and vendor-side account creation, beyond the client's own user administration.
Internet connectivity and landlord infrastructure.

Client dependencies

The provider's service levels are conditional on the following. Where a dependency fails, the affected task is recorded as client-caused and excluded from SLA measurement — but the provider must still flag it in writing on the day, not in the monthly report.

The New Joiner Notification is issued at least three working days before the start date.
The device is released to the provider by Day −1 at 09:00.
The access profile is stated on the notification and any ○ item carries written Department Head approval.
Leaver instructions are issued by an authorised HR signatory.

Authorisation channel

Non-negotiable control

The provider accepts provisioning, access-change and revocation instructions from named authorisers only, through the agreed ticket channel. A request made by WhatsApp, by phone or by a line manager directly is not an authorisation. It must be politely refused and redirected to HR, and the refusal logged. This single rule is the strongest protection both parties have against social-engineering attacks and against disputes over who granted what.

Authorised roles

Authority	May instruct	Held by
Primary HR authoriser	All provisioning, access change and revocation	HR Director
Delegated HR authoriser	Standard joiner and leaver processing	Recruitment Lead
Admin authoriser	Device release, asset movement, hardware faults	Admin Manager
Exception approver	Any access outside the Role Access Matrix	HR Director
Emergency authoriser	Immediate revocation, out of hours, by phone with written confirmation within 1 hour	HR Director or Managing Director
Final escalation	Service disputes and unresolved P1 incidents	Managing Director

The named holders of each authority are recorded on the signature page and re-confirmed at every quarterly service review. The provider must not act on an instruction from a person not on the current list.

Provider contacts

Role	Responsibility	Name / contact
IT Account Manager	Single point of accountability for this SOP and all service levels
Provisioning engineer	Day-to-day joiner, leaver and access work
Escalation contact	P1 incidents and out-of-hours revocation
Service desk	Ticket intake channel and reference numbering

To be completed and countersigned before this procedure takes effect.

SECTION 02

Request Intake and Service Levels

How work reaches the provider, how it is prioritised, and when the clock starts

Intake and lifecycle

1Raise — the authoriser submits the request through the agreed channel. Verbal requests are logged only after written confirmation.

2Acknowledge — the provider issues a reference number and a stated priority. The SLA clock starts at the timestamp of the original request, not the acknowledgement.

3Validate — the provider checks the request against the Role Access Matrix and the authoriser list. Anything unauthorised is returned, not completed.

4Execute — the work is performed to the runbook in Sections 03 to 07.

5Evidence — account identifiers, timestamps and test results are recorded and returned to the requester in writing.

6Close — the requester confirms. A ticket is never closed on the provider's assumption alone.

Measurement rules

The clock starts at the timestamp of the authorised request and runs in working hours, except for P1 and revocation which run in clock hours.
The clock pauses only where the provider is waiting on the client, and only after the wait has been stated in writing on the ticket.
Fixed-date obligations — Day −1 by 12:00, 15:00 and 17:00 — are absolute. They are not relative to when the ticket was picked up.
A missed obligation must be reported by the provider before the deadline expires, together with the recovery plan.
Self-reported breaches are recorded as compliant escalations. Breaches discovered by the client are recorded as failures.

Priority and service level matrix

Priority	Definition and typical examples	Response	Resolution	Updates	Hours
P1	Critical. Company-wide loss of a core service, or a confirmed or suspected security incident. Bitrix24 or email unavailable to all users; account compromise; suspected data exfiltration; leaver revocation instruction.	15 min	4 hours	Hourly	24/7
P2	High. A department cannot work, or a joiner cannot start on time. A team locked out of Bitrix24; mail flow broken for a group; Day −1 provisioning incomplete at 17:00; device build failed the night before a start date.	1 working hr	8 working hrs	Twice daily	Service hours
P3	Medium. A single user impaired with a workaround available. Login failure, password reset, permission correction, application fault, printer or peripheral failure.	4 working hrs	1 working day	Daily	Service hours
P4	Service request. Planned work with a known date. New joiner provisioning, device build, access change, role change, scheduled offboarding, reporting and reviews.	1 working day	Per SOP date, else 3 working days	On completion	Service hours

Fixed obligations — these override priority

Obligation	Trigger	Deadline	Evidence returned to client
Acknowledge New Joiner Notification	Notification received	1 working day	Reference number and confirmed access profile
Microsoft 365 account and licence	Notification received	Day −1 by 12:00	UPN, licence type, MFA state
Bitrix24 user and permission set	Notification received	Day −1 by 12:00	User ID, department, role, supervisor
Drive, groups and role systems	Notification received	Day −1 by 15:00	Access list per matrix item
Device build and security baseline	Device released by Admin	Day −1 by 17:00	Signed build sheet with asset tag and serial
Readiness confirmation to HR	All of the above complete	Day −1 by 17:00	Written readiness statement (Annex 2)
Day-one login and MFA walkthrough	Joiner arrives	First 2 hours	Successful first sign-in logged
Revocation — identity and CRM	Authorised leaver instruction	2 clock hours	Timestamps per system
Revocation — mailbox, drive, groups	Authorised leaver instruction	4 clock hours	Delegation and transfer confirmation
Access Revocation Certificate	Revocation complete	1 working day	Signed certificate (Annex 2)
Device wipe and return to stock	Device received from Admin	5 working days	Wipe confirmation and register update
Monthly service report	Month end	By the 5th	Report pack per Section 10
Quarterly access reconciliation	Quarter end	Within 10 working days	Exception list signed by both parties

Where a fixed obligation and a priority level conflict, the fixed obligation applies. A P4 service request to provision a joiner still carries a hard Day −1 deadline.

SECTION 03

Onboarding Runbook — Identity and Microsoft 365

Executed on receipt of the New Joiner Notification; complete by Day −1 at 12:00

Pre-checks before any account is created

1Confirm the request came from a named authoriser. If not, return it to HR and log the refusal.

2Confirm the notification carries a standard job title from the approved list. A free-text title is returned for correction — it determines the entire access profile.

3Map the title to an access profile column in the Role Access Matrix and list every item to be provisioned.

4Confirm written Department Head approval exists for every ○ item. Provision nothing marked –.

5Check licence availability. If none is free, request one from Admin the same day — never delay to Day −1.

6Check for a name collision in the directory and apply the convention in Annex 1.

Account creation

7Create the user with UPN firstname.lastname@company-domain, matching the primary SMTP address.

8Complete the directory attributes in full — display name, job title, department, manager, office and mobile. These populate the address book, the signature and the HR reconciliation, so blanks are treated as an incomplete build.

9Set the usage location and assign the licence stated in the notification.

10Set a single-use password and require a change at first sign-in.

11Enforce multi-factor authentication registration at first sign-in. MFA is mandatory for every account without exception, including shared and role accounts.

12Issue credentials to HR only, by the agreed secure channel. Never to a personal email address, and never in the same message as the username.

Mailbox and group configuration

13Add to the distribution lists and security groups for the department, per the matrix.

14Grant shared drive and document library permissions at the folder level defined for the role — inherited access only, no one-off grants to individuals.

15Confirm external auto-forwarding is blocked by policy on the tenant, and that no forward exists on the new mailbox.

16Confirm the retention and archive policy applies to the mailbox.

17Where the role requires a shared or role mailbox, grant access through a group, never by adding the individual directly.

Evidence — mandatory before the ticket closes

Record and return to HR

UPN and primary email address, with the creation timestamp.
Licence type assigned and the licence count remaining.
Every group and permission granted, itemised against the matrix.
MFA enrolment state.
Confirmation that a test sign-in succeeded.
Name of the engineer who performed the build.

Why this matters: the provisioning record is what makes revocation provable later. An account created without a written record is an account nobody can be certain was removed.

Never do these

Never copy an existing user's permissions as a shortcut. Permission creep is how agents end up with manager-level visibility.
Never create the account against a personal email address or a personal phone number for recovery.
Never grant global administrator, exchange administrator or equivalent to a standard employee account.
Never share one licence or one login between two people, including temporary cover.
Never leave a test or temporary account enabled after the build is complete.

SECTION 04

Onboarding Runbook — Bitrix24 CRM and HR

Bitrix24 is the system of record for both CRM and HR; complete by Day −1 at 12:00

User creation and structure

1Invite the user with the company email address as the login. Personal addresses are never used, because they cannot be revoked by the client.

2Place the user in the correct department node in the company structure and set the supervisor to the reporting line on the notification. No user is left outside the structure — orphan users break approvals, reporting and access inheritance.

3Set the position field to the standard job title exactly as issued, so headcount and access audits reconcile.

4Complete the profile — work phone or extension, mobile, department, start date.

5Apply the role permission set for the access profile. Use the standard role; do not build a bespoke permission set for an individual.

CRM permission principles

Role	Record visibility	Export	Admin rights
Sales agent	Own leads, deals and contacts only	Disabled	None
Sales manager	Own plus subordinate records in the department	On approval, logged	None
CRM officer	Department or all, per appointment	On approval, logged	CRM settings only
Marketing	Read access for campaign purposes	Disabled	None
Admin	As appointed	On approval, logged	Limited, named
Accounts	Deal financial fields only	On approval, logged	None
HR	No CRM record access	–	HR module only
Conveyancer	Deals assigned to conveyancing	Disabled	None

Elevated rights — administrator, full export, cross-department visibility — are granted to named individuals only, with written HR Director approval and a quarterly re-justification.

Modules and access

6Add the user to the correct workgroups and project spaces for the department.

7Confirm Drive access — personal drive, department folders and shared documents at the role-appropriate level.

8Confirm HR self-service — the employee can see the structure, request absence and view their own record. Confirm that they cannot see other employees' personal data.

9Where the role uses telephony, assign the extension, configure call recording per policy, and test an inbound and an outbound call.

10Add to the relevant chat channels; enrol the mobile app and confirm push notifications work.

11Confirm the user appears correctly in reports and in the lead assignment or distribution rules for their team.

Data protection inside Bitrix24

Employee personal data

Passport, Emirates ID, visa and bank details are held on the HR employee record with restricted visibility — HR and the authorised approver only. The provider must confirm at build time that:

These fields are not visible to line managers or to the employee's colleagues.
They are not carried into any CRM field, custom field or exportable list.
No copy of the data exists in a shared drive folder or an open spreadsheet as a working file.

Where the provider finds personal data outside the HR record, it is reported to the HR Director as a finding — it is not quietly deleted, because a copy may be the only record.

Evidence

Return to HR

Bitrix24 user ID, department node and supervisor.
Role permission set applied, and any exception with its approval reference.
Telephony extension where issued.
Confirmation of a successful test sign-in on both desktop and mobile.

SECTION 05

Device Build Standard and Day-One Handover

Device released by Admin at Day −1 09:00; build complete and tested by 17:00

Build checklist

#	Step	Confirmed
1	Record asset tag, make, model and serial number; match to the Asset Register entry
2	Clean operating system install or verified factory reset — never a hand-me-down profile
3	All operating system and firmware updates applied
4	Full-disk encryption enabled and the recovery key escrowed to the tenant
5	Endpoint protection installed, updated and reporting to the console
6	Local firewall enabled
7	The employee account is a standard user, not a local administrator
8	Separate, named local administrator account with a managed password
9	Screen lock enforced at 5 minutes with a password on wake
10	Microsoft 365 apps installed and signed in; mail, calendar and contacts syncing
11	Bitrix24 desktop app installed and signed in; chat and drive verified
12	Browser installed with company bookmarks and the portal shortcuts for the role
13	Role applications installed per the Role Access Matrix
14	Printer and network resources mapped
15	VPN or remote access configured where the role requires it
16	Manufacturer bloatware and any trial software removed
17	Backup or sync of the documents folder configured to the company drive
18	Every provisioned account signed into once to prove it works before handover
19	Device labelled and packaged; build sheet signed by the engineer
20	Written readiness confirmation issued to HR by 17:00

Day-one handover

1Attend within the joiner's first two hours, in person or by scheduled remote session.

2Walk the joiner through first sign-in and password change on the device, not over the phone.

3Complete MFA enrolment on the joiner's own device and confirm a successful challenge.

4Verify mail, Bitrix24, drive and the role systems all open for the joiner, in front of the joiner.

5Configure the mobile — mail profile and the Bitrix24 app — where the role requires it.

6Cover the four security basics: password hygiene, phishing, device locking, and how to report an incident.

7Give the joiner the service desk reference and explain how to raise a ticket.

8Log the successful first sign-in and close the onboarding ticket with HR's confirmation.

The test that prevents most day-one failures

Signing into every account once on Day −1 costs ten minutes and catches the three failures that account for most bad first days: a licence that was never actually assigned, a permission set applied to the wrong department, and a password that expired between creation and the start date. A build is not complete because the accounts exist. It is complete because they were used.

If the device is late

Notify HR and Admin in writing the moment the Day −1 09:00 release is missed — before the deadline passes, not after.
Provision every account regardless, so the joiner can work from a temporary device.
Offer a loan device from stock where one exists, and record it against the Asset Register.
Record the delay as client-caused with the timestamp, so the monthly report is accurate rather than contested.

SECTION 06

Change, Role Change and Access Request Control

How access is added, altered and removed between joining and leaving

Standard access change

1Request received from a named authoriser, stating the employee, the system, the exact access required and the business reason.

2Provider checks it against the Role Access Matrix. If the item is ● for that role, proceed. If ○, require the Department Head approval in writing first. If –, require HR Director approval as a recorded exception.

3Apply the change through the standard role or group. Never as a direct individual grant.

4Record what changed, when, on whose authority, and against which approval reference.

5Confirm to the requester and to HR, so the employee record stays accurate.

Role change — the highest-risk routine event

Add and remove in the same ticket

When an employee moves role or department, the matrix is re-applied in full. The single most common access failure in any company is the internal mover who accumulates every permission they have ever held. The provider must therefore:

List the current access profile before making any change.
List the target profile from the new role's matrix column.
Execute additions and removals in the same change, and evidence both.
Update the department node and supervisor in Bitrix24.
Reassign or re-scope CRM record visibility to match the new role.
Return a before-and-after statement to HR.

A role change ticket that only contains additions is returned as incomplete.

Exceptions register

Every grant outside the matrix is an exception. Exceptions are not refused on principle — the business sometimes needs them — but they are never invisible.

Field	Requirement
Employee and role	Named, with the current access profile
Access granted	The specific system, scope and level
Business justification	Written by the requesting Department Head
Approver	HR Director, in writing
Grant date	Recorded by the provider
Review date	Mandatory; maximum 90 days
Outcome at review	Extended with fresh approval, or removed

Leave of absence and suspension

Extended leave over 30 days — sign-in disabled, licence reclaimed, account retained. Restored on return.
Suspension or investigation — treated as an immediate revocation under Section 08 until HR instructs otherwise. Data is preserved, never deleted.
Probation failure — treated as a standard leaver on the confirmed last working day.

Quarterly access review

1Provider exports the full list of active accounts across Microsoft 365 and Bitrix24, with role, department and last sign-in date.

2HR supplies the current employee list.

3Both are reconciled. Any account without a matching active employee is a finding, and is disabled within one working day of confirmation.

4All elevated rights are listed and re-justified in writing, or removed.

5Accounts with no sign-in for 60 days are flagged to HR for a decision.

6The signed exception list is filed by both parties.

SECTION 07

Offboarding Runbook — Timed Revocation

Executed on an authorised leaver instruction; order matters more than speed

Sequence rule — preserve before you remove

Data is lost when access is removed before ownership is transferred. Removing a licence deletes the mailbox after the grace period. Deleting a user can orphan their drive content and detach their CRM history. The provider therefore always performs transfer before removal, in the order below . A user account is never deleted as part of routine offboarding: disable, preserve, then reclaim.

Before the clock starts

Confirm the instruction came from an authorised HR signatory.
Confirm the mailbox treatment and the named delegate were agreed at LWD −1.
Confirm the Line Manager has executed the Bitrix24 pipeline reassignment. If records are still owned by the leaver, revoke sign-in first and flag it immediately — do not wait.

Revocation sequence

Order	System	Action	Deadline	Evidence
1	Microsoft 365 identity	Disable sign-in, reset the password to a value nobody holds, revoke all refresh tokens and terminate active sessions	T + 2 hrs	Timestamp and admin action log
2	Multi-factor authentication	Revoke registered methods so a retained phone cannot re-authenticate	T + 2 hrs	Timestamp
3	Bitrix24	Confirm zero owned records remain, then deactivate the user and remove all permission sets. Do not delete the user	T + 2 hrs	User ID and deactivation timestamp
4	Mobile and remote access	Remove company data from the mobile profile; disable VPN and any remote access	T + 2 hrs	Confirmation of removal
5	Drive and documents	Transfer ownership of personal drive and document libraries to the named manager	T + 4 hrs	Transfer confirmation with target owner
6	Mailbox	Convert to a shared mailbox, apply the agreed delegation, and set any approved forwarding with an end date	T + 4 hrs	Delegation confirmation
7	Groups and lists	Remove from all distribution lists, security groups, workgroups and chat channels	T + 4 hrs	Itemised removal list
8	Role systems and portals	Disable or reassign the property system, portal accounts, design and finance tools per the matrix	T + 4 hrs	Per-system confirmation
9	Telephony	Release the extension, reroute the direct line, and preserve call recordings per policy	T + 4 hrs	Extension released
10	Licences	Reclaim all licences only after steps 5 and 6 are confirmed complete	T + 8 hrs	Licence count returned to Accounts
11	Certificate	Issue the signed Access Revocation Certificate listing every system and the time revoked	1 working day	Certificate to HR (Annex 2)
12	Device	Recover from Admin, back up any local business data, wipe, re-image and return to stock	5 working days	Wipe confirmation and register update
13	Residual review	Re-run the access check across every matrix system and confirm nothing remains	30 days	Nil-return statement to HR
14	Retention	Review the shared mailbox, end forwarding and archive per the retention policy	30 days	Archive confirmation

Data the provider must preserve, not delete

Mailbox contents, including sent items, for the retention period.
Drive and document content, transferred to a named owner.
Bitrix24 records, activities and call history — the deactivated user record is retained so history stays attributable.
Any local data found on the device, backed up before the wipe.

Common failures this sequence prevents

Licence removed first, mailbox deleted after the grace period, client correspondence gone.
User deleted in Bitrix24, deal history detached, commission disputes become unprovable.
Sign-in disabled but MFA methods left registered, allowing re-authentication after a password reset.
Personal mobile still holding a synced mailbox because only the desktop was addressed.
Portal accounts forgotten because they sit outside the two core platforms.

SECTION 08

Immediate Revocation and Security Incidents

When the standard sequence is too slow

Immediate revocation

Instructed by the HR Director or Managing Director, by phone if necessary, confirmed in writing within one hour. Applies to gross misconduct, a hostile departure, or any suspicion that company or client data is at risk. The order inverts: access is removed before the individual is informed.

T − 15 min

Instruction received and verified against the authoriser list. Confidentiality absolute — no other client contact is informed.

T + 0

All sign-ins disabled, sessions and tokens revoked, MFA methods removed, password reset.

T + 5 min

Bitrix24 deactivated. Mobile access removed. Remote access and VPN disabled.

T + 15 min

Device remotely locked where the capability exists. Local data preserved, not wiped.

T + 30 min

Mailbox delegated to the named manager. Drive ownership transferred.

T + 2 hrs

Full written confirmation to the HR Director listing every action and its timestamp.

T + 1 day

Access Revocation Certificate and, where relevant, a preserved evidence statement.

The provider does not contact the individual, does not respond to them, and does not restore any access on their request — only on written instruction from the HR Director.

Security incident response

A suspected account compromise, phishing success, malware infection or data exposure is a P1 and follows this sequence regardless of the hour.

1Contain — disable the affected account, revoke sessions and tokens, isolate the device from the network.

2Notify — inform the HR Director and Managing Director within 15 minutes with what is known and what is not.

3Assess — establish scope: which accounts, which data, what period, whether client data is involved, whether mail rules or forwards were created by the attacker.

4Preserve — capture and retain logs before any remediation overwrites them.

5Remediate — reset credentials, re-enrol MFA, remove attacker-created rules, forwards, delegations and app consents, rebuild the device if compromised.

6Restore — return the user to service only after the HR Director confirms.

7Report — written incident report within 2 working days: timeline, root cause, data affected, actions taken, and what will prevent a recurrence.

Escalation to the client is not optional

The provider must not attempt to resolve a suspected breach quietly before telling the client. Where client or customer personal data may have been exposed, the client may carry notification obligations with statutory deadlines, and those deadlines run from the moment of awareness — not from the moment the provider finishes investigating. Late notice removes the client's ability to comply.

Standing prevention duties

MFA enforced on 100% of accounts, reported monthly.
External auto-forwarding blocked at tenant level.
Administrator accounts separate from day-to-day accounts, and never shared.
Alerting enabled for impossible-travel sign-ins, new mail rules and mass downloads.
Endpoint protection reporting on every device, with exceptions reported.

SECTION 09

Security Baseline and Technical Standards

The minimum configuration the provider maintains and reports against

Control	Standard	Verification
Multi-factor authentication	Mandatory on every account, including shared, role and administrator accounts	Monthly report, 100% target
Password policy	Minimum length enforced, no forced periodic expiry, breached-password blocking enabled	Tenant policy screenshot
Administrator accounts	Separate named admin accounts, MFA enforced, never used for daily work, reviewed quarterly	Quarterly review
Legacy authentication	Blocked at tenant level	Tenant policy
External auto-forwarding	Blocked at tenant level; exceptions individually approved	Monthly report
Conditional access	Sign-in risk and location policies applied per client instruction	Policy list
Device encryption	Full-disk encryption on every company device, keys escrowed	Build sheet and device report
Endpoint protection	Installed, updating and reporting on every device	Monthly console report
Patching	Operating system and application updates applied within the agreed window	Monthly compliance percentage
Local administrator rights	Removed from standard users; exceptions approved and time-limited	Quarterly review
Backup and sync	Company data held in Microsoft 365 or Bitrix24, not solely on the device	Configuration check at build
Screen lock	5 minutes with password on wake, enforced by policy	Policy state
Audit logging	Enabled and retained for the agreed period across both platforms	Retention setting
Licence position	Assigned, unassigned and reclaimable licences tracked	Monthly report
Asset accuracy	Every device attributable to a named holder or to stock	Monthly reconciliation with Admin

Documentation the provider maintains

Access Provisioning Log — every account created, changed or removed, with authority and timestamp.
Build sheets — one per device, signed, with asset tag and serial.
Revocation certificates — one per leaver.
Exceptions register — every grant outside the matrix, with its review date.
Tenant configuration record — current policy state for the controls above, updated on change.
Asset list — synchronised with the client's Asset Register monthly.

All of the above are the client's records. On termination of the engagement they are handed over in a usable format, together with administrative control of both platforms, within ten working days.

Handover and continuity

Continuity obligations

The client holds an emergency administrator account for both platforms, in a sealed credential, tested at each quarterly review.
No configuration, licence or domain is registered in the provider's own name.
Named cover is identified for the provisioning engineer, so joiner and leaver dates do not depend on one person's availability.
Planned absence over three working days is notified in advance with the cover arrangement stated.

Confidentiality

The provider will encounter employee personal data, client contact data and commercial information. Access is on a least-privilege, task-necessary basis only. Data is not copied to provider systems beyond what is needed to deliver the service, is not retained after the task, and is never used for any other purpose. Any access to a mailbox or record outside a specific authorised ticket must be logged and reported.

SECTION 10

Reporting, KPIs and Service Governance

How performance is evidenced rather than asserted

Monthly service report — due by the 5th

Section	Content
Service level performance	Tickets by priority, response and resolution attainment, every breach with its cause and the recovery action
Joiners	Each joiner processed, each fixed obligation met or missed, and the provisioning evidence reference
Leavers	Each leaver processed, time from instruction to full revocation, certificate reference
Access position	Total active accounts by platform, accounts created, changed and removed, licence position
Exceptions	Open exceptions with review dates, and any overdue for review
Security	MFA coverage, patch compliance, endpoint coverage, incidents and near-misses
Assets	Devices in stock, deployed and pending wipe; reconciliation differences with Admin
Risks and recommendations	Anything the provider believes the client should act on, with a stated impact
Client-caused delays	Late notifications, late device releases and missing approvals, with dates

Provider KPIs

Indicator	Target
Fixed onboarding obligations met on time	≥ 98%
Joiners with complete provisioning evidence	100%
Day-one failures attributable to the provider	0
Revocations completed within 2 hours of instruction	100%
Revocation certificates issued within 1 working day	100%
P1 response within 15 minutes	100%
P2 and P3 SLA attainment	≥ 95%
MFA coverage across all accounts	100%
Quarterly reconciliation findings closed within 5 working days	100%
Monthly report delivered by the 5th	100%

Quarterly service review

Attended by the IT Account Manager and the HR Director, with the Managing Director invited. Standing agenda:

1Service level performance for the quarter, and every breach reviewed individually.

2Access reconciliation — findings, closures and anything still open.

3Elevated rights and exceptions — re-justified or removed.

4Security posture against the Section 09 baseline.

5Licence and asset position, with cost implications.

6Client-caused delays and how to remove them — this is a two-way review.

7Authoriser list re-confirmed and the emergency administrator credential tested.

8Changes to this procedure agreed and versioned.

Service failure handling

A breach self-reported before the deadline, with a recovery plan, is a managed event.
A breach discovered by the client is a service failure and is recorded as such.
Three failures on the same obligation in a quarter trigger a formal service review with the Managing Director.
Any failure that leaves a leaver's access active, or exposes client data, is escalated immediately regardless of count.

The spirit of this document

The purpose is not to catch the provider out. It is to make the service provable — so that when the client is asked who had access to what and when, the answer exists in writing rather than in someone's memory. Every requirement here produces a record, and every record protects both parties.

ANNEX 1

Naming Conventions and Standards

Applied without exception, because inconsistency is what breaks audits

Item	Convention	Example
User principal name	firstname.lastname@domain, lowercase, no accents or apostrophes	ahmed.hassan@…
Duplicate name	Append a middle initial; a number only as a last resort	ahmed.k.hassan@…
Display name	Firstname Lastname, as per passport	Ahmed Hassan
Shared mailbox	Function based, never person based	accounts@…
Distribution list	dl- prefix and function	dl-sales-offplan
Security group	sec- prefix, system, role	sec-crm-agent
Drive folder group	grp- prefix and department	grp-marketing
Device asset tag	LPH-DEPT-NNN	LPH-SLS-042
Device hostname	Matches the asset tag	LPH-SLS-042
Bitrix24 login	Identical to the company email address	ahmed.hassan@…
Bitrix24 position	The approved standard job title only	Property Consultant
Bitrix24 department	The company structure node, with a supervisor set	Sales — Off-plan
Ticket reference	Provider format, quoted in all correspondence

Standard job titles

Access profiles are driven by job title. The provider must reject any notification carrying a free-text or improvised title and request the approved standard title from HR. This is not pedantry — a title that does not appear in the Role Access Matrix has no defined access profile, which means the engineer would be guessing at what the person should be able to see.

Directory attributes — all mandatory

Display name, first name, last name
Job title — standard title only
Department and office location
Manager — must resolve to a real account
Mobile and work extension
Employee start date
Usage location and licence

A build with blank directory attributes is incomplete. These fields drive the address book, the email signature, approval routing in Bitrix24 and the quarterly reconciliation.

Access profile letters

The New Joiner Notification states an access profile taken from the Role Access Matrix. The provider provisions that column exactly.

Profile	Matrix column
A	Sales agent
B	Sales manager
C	CRM officer
D	Marketing
E	Admin
F	Accounts
G	HR
H	Conveyancer
X	Non-standard — requires an HR Director exception before any account is created

Rounding rule for ambiguity

Where a notification is ambiguous, the provider provisions the lesser access and asks. Under-provisioning creates a ticket. Over-provisioning creates an exposure that may not be found for months.

ANNEX 2

Evidence Templates

The two documents that make the service provable

Template A — Day −1 Readiness Confirmation

To: HR / Recruitment From: IT Service Provider Ref: ______________

Joiner: ____________________ Standard title: ____________________
Department: ______________ Access profile: ______ Start date: ____________

Item	Provisioned	Identifier / note	Tested
Microsoft 365 account and licence
Multi-factor authentication enforced
Mailbox, distribution lists and groups
Shared drive and document permissions
Bitrix24 user, department and supervisor
Bitrix24 role permission set
Bitrix24 workgroups and chat
Telephony extension (if applicable)
Role systems and portals per matrix
Device build and security baseline
Exceptions applied (with approval ref.)

I confirm every item above was provisioned per the Role Access Matrix and signed into successfully before handover.

Engineer — name, signature, date/time

HR — received and accepted

Template B — Access Revocation Certificate

To: HR Director From: IT Service Provider Ref: ______________

Leaver: ____________________ Last working day: ____________
Instruction received: ______________ (date/time) Authorised by: ______________
Exit type: Standard □ Immediate □

System	Action taken	Time revoked
Microsoft 365 sign-in and sessions
Multi-factor authentication methods
Bitrix24 user
Bitrix24 records reassigned to
Mailbox — converted / delegated to
Drive and documents — transferred to
Groups, lists and chat channels
Role systems and portals
Telephony extension
Mobile and remote access
Licences reclaimed
Device received and wiped

I certify that all access listed above has been revoked, that company data was preserved and transferred before removal, and that no residual access remains known to the provider.