Customer Data Ownership and Access Policy

1. Purpose

Our promise is simple: what’s in your name is yours, and your data is always yours. Anything we hold in our name for you, such as an app published under our developer accounts, we license to you until it’s transferred to you. This policy sets out how we make that real. It covers who owns what, how we access customer environments, and what happens when an engagement ends.

2. Scope

All services Inforge provides, and every person who works for or with Inforge, including casual staff and subcontractors.

3. Ownership

1. Tenancies and subscriptions. Microsoft 365 tenancies, Azure subscriptions, domain names, and software accounts are created and held in the customer’s name, never ours. The only exception is an app the customer chooses to have us hold (item 7).
2. Licences. Licences are assigned to the customer. Where we resell licences (for example through the Microsoft Cloud Solution Provider program), the customer can move them to another provider or buy direct at any time, subject only to the vendor’s own terms.
3. Data. All customer data stays the customer’s property. We never claim ownership of it, use it for our own purposes, or use it to train AI models.
4. Administrator accounts. The customer always keeps its own global administrator or owner accounts, including emergency (break-glass) accounts. We never hold the only way in.
5. Documentation. Environment documentation, network diagrams, configuration records and runbooks that we produce for a customer belong to that customer and are available to them at any time.
6. Custom work. Bespoke code, configuration and designs we create for a customer belong to the customer once paid for, except for an app the customer chooses to have us hold (item 7). If we use reusable components or tools of our own, the customer receives a perpetual licence to use them as part of the solution. The source code of a customer-owned solution is kept in a repository the customer owns or can access.
7. Apps we hold for the customer. For a mobile or web app, the customer chooses up front whether it is published and run under their own developer and hosting accounts, or under ours, and the order records that choice. If the customer chooses ours, we own the app and its code, and the customer has a licence to use the app while our service continues. The customer’s data in the app is always the customer’s (item 3).

4. How we access customer environments

1. Delegated, not owned. The customer grants us access. We use the vendor’s purpose-built delegation tools where they exist, such as Microsoft GDAP (Granular Delegated Admin Privileges) for Microsoft 365 and Azure Lighthouse for Azure.
2. Least privilege. We request only the roles needed for the agreed services. Roles are time-bound where the platform supports it, and highly privileged roles are activated just in time.
3. Named accounts only. Every person has their own named account, protected by phishing-resistant multi-factor authentication where available. We do not use shared logins.
4. Visible. Our access is logged in the customer’s own audit logs, and the customer can see and review it at any time.
5. Reviewed. We review our access with each managed services customer at least every six months, and remove anything no longer needed.
6. Revocable. The customer can reduce or remove our access at any time without needing our help.
7. Credentials. Any credentials we need are stored in an encrypted password vault, with access restricted to the people working on that customer. Customer-owned credentials are handed over on request.

5. When an engagement ends

1. No exit fees. We do not charge to leave.
2. Handover pack. Within 10 business days of the end date, we provide a handover pack: current documentation, credentials we hold, configuration records, open issues, and licence and subscription details.
3. Transition help. We will work with an incoming provider in good faith. Transition work beyond the handover pack is charged at standard rates.
4. Access removed. We remove all of our access within 1 business day of the end date (or on the customer’s request) and confirm this in writing.
5. Data returned or destroyed. Any customer data we hold outside the customer’s own systems is returned or securely destroyed, at the customer’s choice, and we confirm destruction in writing.
6. No hostage-taking. We will never withhold access, credentials, data or documentation as leverage, including during a billing dispute.
7. Apps we hold. If we hold an app for the customer (section 3, item 7), we first ask whether they want to keep using it. If they do, we transfer ownership of the app, its code, its store listings and its hosting to the customer’s own accounts, with no fee from us. If they don’t, we wind the app down and archive the code. Either way, the customer’s data is returned or destroyed as in item 5.

6. Responsibilities

• Director: owns this policy, approves access models for new services, and handles any exception.
• All staff and contractors: follow this policy, request only the access they need, and report any access that seems wrong.

7. Exceptions

Any exception must be agreed in writing with the customer before it applies.

8. Related documents

Privacy Policy; Information Security Policy; ICT Acceptable Use Policy; Master Service Agreement.