Security, privacy and trust when we work in your Microsoft environment
Controlled access, confidentiality, least privilege, traceability and a way of working tailored to each organisation’s requirements.
Microsoft 365, Microsoft Azure, cybersecurity, migration and managed services projects may require access to critical systems. At MSAdvance, we treat that access as a responsibility. Before we begin, we define what we need, why we need it, for how long, which customer controls we must follow and how access should be removed when it is no longer required.
The answers Security, IT, Legal and Procurement usually need first
The detail always depends on the service being delivered, but these principles summarise how we approach access to customer environments.
Yes. We can sign an NDA before sensitive technical information is shared or discovery begins.
Yes. We provide a global remote service and adapt access to the customer’s restrictions.
Not by default. We request the role appropriate to the task and use elevated privileges when they are required.
Yes, when the tenant and licensing support it. It is particularly well suited to temporary access.
Yes, when it is appropriate for the service and the partner relationship established with the customer.
Yes. It can be appropriate for delegated administration of subscriptions or resource groups.
That is not the objective. We aim to minimise exports and work directly with the platforms required for the service.
We review access created specifically for the project and remove or reduce permissions that are no longer required.
This Trust Center describes our general approach. The controls, service levels, responsibilities and obligations that apply to a specific customer are those defined in the relevant contractual and technical documentation.
Access is designed for the work that must be performed, not to make administration easier
Microsoft recommends combining least privilege, time-limited access, MFA, periodic review and auditing. Those principles align with how we design projects and managed services.
Confidentiality
We can formalise an NDA before exchanging architecture details, domains, inventories, security information or data relating to corporate operations.
Least privilege
We request permissions aligned with the tasks to be performed and avoid increasing privileges simply for convenience.
Strong authentication
We favour MFA and stronger identity controls for accounts that perform administrative functions.
Temporary access
Where the environment supports it, PIM and other JIT models reduce the need for permanently active elevated privileges.
Traceability
We use Microsoft audit capabilities together with project documentation so that relevant changes can be explained.
Data minimisation
If a task can be completed without exporting information outside the environment where it is needed, we avoid creating additional copies.
Business alignment
We adapt to maintenance windows, approvals, VPN, VDI, bastions, geographic restrictions and internal processes where they apply.
Secure closure
Project closure includes reviewing permissions, applications, accounts and artefacts that no longer serve an operational purpose.
Segregation of duties
Profiles and permissions can differ according to responsibility, workload and approval requirements.
Change control
Having technical privileges does not mean production changes should be made without the required coordination.
Applications under control
Service principals, consent grants and Microsoft Graph permissions are treated as identities with security impact.
Customer governance
The customer retains governance of its tenant and can review, change or remove granted access.
Physical location should not prevent access to the right specialist
MSAdvance provides remote services to organisations in different countries and time zones. Our remote model makes it possible to bring in specialised expertise without giving up access controls, coordination or traceability.
Remote does not mean unrestricted access
Remote access can be provided through named accounts protected with MFA, but we can also adapt to more restrictive architectures when the organisation requires them.
For enterprise customers, third-party administration is often governed by corporate VPN, VDI, jump servers, bastions, privileged workstations, Conditional Access, approved IP ranges, geographic restrictions or defined access windows. We review those requirements during technical onboarding.
Global service does not mean indiscriminate information transfer
The professional’s location, data residency, the infrastructure used by a tool and whether an international transfer takes place are separate issues.
If the customer has specific requirements relating to jurisdiction, residency, territorial access or approved providers, they should be incorporated into the service design before work begins.
Technical trust starts before the first administrative account is issued
Discovery can reveal sensitive information even before a project is signed: acquisitions, domains, vulnerabilities, users, topology, data volumes, critical applications or corporate decisions that are not yet public.
Non-Disclosure Agreement
We sign NDAs when the customer or scenario requires them, including before detailed technical information is shared.
Statement of Work
A clear technical scope helps distinguish included systems, responsibilities, exclusions, deliverables and acceptance criteria.
Data protection
When the service involves processing personal data on the customer’s behalf, the relationship should be documented in line with the applicable role and obligations.
Security Addendum
We can review security addenda, supplier policies and internal controls that need to be incorporated into service delivery.
We can work with the customer’s own documentation
In enterprise projects, Procurement, Legal, Security or Data Protection teams often have their own clauses, addenda, questionnaires and supplier onboarding processes.
The objective is for the contract, access architecture and day-to-day operation to tell the same story.
Every access grant should answer three questions: what, why and until when
We treat permissions as part of project design, not as a generic prerequisite that is granted once and then left in place indefinitely.
Need
We identify the tasks and resources that require access.
Scope
We determine the workload, role and scope required.
Approval
The customer grants or approves the access.
Use
Access is used for the agreed scope.
Review
We assess whether it is still required.
Removal
Access is reduced or removed when the need ends.
Global Administrator is not our starting point for every project
Some operations may require elevated privileges, but many tasks can be completed with specific roles, read access, workload permissions or temporary elevation.
Microsoft recommends granting a specific set of permissions, over a specific scope and for a specific period. That is the principle we use when designing access.
An assessment, a migration and a managed service should not automatically use the same privilege model
The following matrix is indicative. The final design depends on the technology, required features, licensing and scope.
| Scenario | Objective | Preferred model | Elevated access | Closure |
|---|---|---|---|---|
| Assessment Microsoft 365 | Review configuration, users, security, licensing and risk. | Read access and audit roles where they are sufficient. | Usually limited when no changes are being made. | Remove temporary access and deliver the findings. |
| Tenant-to-Tenant | Move identities, email, OneDrive, SharePoint, Teams and other objects. | Workload-specific roles, applications and permissions required by the selected tools. | May be required for specific tenant-level operations. | Review applications, consent grants, accounts and access relationships. |
| Google Workspace to Microsoft 365 | Migrate email, calendars, contacts and data to Microsoft 365. | Specific source and destination permissions based on the selected tool and workload. | Depends on the platform and migration method. | Revoke tool access and temporary credentials. |
| Microsoft Entra / Security | Design MFA, Conditional Access, PIM, roles and controls. | Specific identity and security roles. | Some critical changes require privileged roles. | Validate access, break-glass arrangements and documentation. |
| Microsoft Intune | Configure devices, compliance, applications and policies. | Intune roles and appropriate scopes. | Should not automatically require Global Administrator. | Validate policies and remove project-specific access. |
| Azure Architecture | Design or implement resources, networks, policies and services. | Azure RBAC at subscription, resource-group or resource scope; Azure Lighthouse where appropriate. | Owner or User Access Administrator only when the task requires it. | Review RBAC, service principals and delegations. |
| Managed Services | Ongoing administration and support. | GDAP, Azure Lighthouse, granular roles and dedicated groups where appropriate. | Preference for temporary elevation for sensitive tasks. | Formal offboarding when the service ends. |
The account that administers the environment is part of the security perimeter
Microsoft recommends least privilege, MFA for administrative accounts, PIM for just-in-time access and periodic permission reviews. Privileged access requires particular care in its design.
Strong authentication for administrative access
We favour MFA for identities used in administration. Where the customer uses Conditional Access, we can operate within the policies they have established.
We prioritise identities that allow human activity to be associated with an identifiable person or function.
MFA, location, device, network and other controls can form part of the access model.
Just-in-time, time-limited privileges
Microsoft Entra Privileged Identity Management allows a user to be eligible for a role and activate it for a limited period. It can include MFA, approval, justification and notifications.
Reduces the amount of time an identity keeps elevated privileges active.
Temporary access can expire automatically according to the configured policy.
The customer’s emergency accounts are not part of MSAdvance’s normal operational access
Microsoft recommends maintaining emergency access accounts for scenarios where normal administrative accounts cannot be used. Their purpose is customer resilience, not the day-to-day administration of a third-party provider.
Break-glass accounts should remain under the organisation’s governance and emergency procedures.
Any exceptional use should correspond to an authorised, traceable scenario.
GDAP and Azure Lighthouse enable more controlled delegated-administration relationships
For recurring services, the objective should not be to create a permanent Global Administrator account in every customer tenant when a more appropriate delegated model is available.
Granular Delegated Admin Privileges
Microsoft defines GDAP as a mechanism for partners to configure granular, least-privilege and time-bound access to customer workloads.
Azure Lighthouse
It allows subscriptions or resource groups to be delegated with specific roles while the resources remain in the customer’s tenant.
Revocable access
The customer retains the ability to review and remove the delegation when it is no longer required.
Delegated administration does not remove the need to design roles properly
Both GDAP and Azure Lighthouse support a more granular model, but the specific role assignments remain a security decision.
For tasks that require exceptional privileges, we prefer to treat elevation as a specific need rather than the normal state of the relationship.
A service principal with broad permissions can be as sensitive as an administrative account
Migrations, automation and administration tools can use enterprise applications, OAuth and Microsoft Graph. Those permissions are part of the security surface.
Delegated permissions
The application acts on behalf of a user, and its access depends on the granted scopes and the effective access of that identity.
Application permissions
The application can operate without a signed-in user. For that reason, application permissions require particularly careful review.
Least privilege in Microsoft Graph
Microsoft recommends selecting the lowest level of permission that allows the required operation to be performed.
Admin consent
If a tool requires admin consent, we need to understand which permissions it requests and why.
Service principals
Application identities created for a project should be included in the security and closure review.
Revocation
Consent grants and applications that no longer serve a purpose should be removed or reduced.
End-user passwords are not a normal mechanism for modern administration
Microsoft 365, Microsoft Graph and modern tools allow us to work with OAuth, applications, roles and authorisation mechanisms without knowing each user’s password.
Some legacy systems, integrations or source platforms may require technical credentials. When that happens, we agree with the customer which credential is needed, who provides it, how it will be used and when it should be rotated or removed.
The same principle applies to client secrets, certificates, API keys and tokens. They should not be treated as indefinite-use text values without a lifecycle.
Accessing information to deliver a project does not make that information an MSAdvance asset
Processing must correspond to a specific purpose, the contracted scope and the applicable instructions when MSAdvance acts on the customer’s behalf.
Data minimisation
We aim to avoid unnecessary exports and copies when the work can be completed on the platform itself or through appropriate cloud tools.
Purpose limitation
Access should relate to the service we are providing and the technical need that justifies it.
Controller and processor
When we act as a processor, the applicable obligations and processing activities are governed contractually with the controller.
Retention
Temporary artefacts, logs or exports should not be retained indefinitely without a technical, contractual or legal need.
International transfers
Where access or international-transfer implications exist, they are assessed in the context of the architecture, providers and applicable requirements.
Security appropriate to the risk
The GDPR requires appropriate technical and organisational measures, taking into account the nature, context, purpose and risk of the processing.
The contract and technical design should reflect the same data flow
The EDPB notes that the controller-processor relationship must be governed by contract and that the processor must process data in accordance with the controller’s instructions, maintain confidentiality and apply appropriate security.
In complex projects, the tool architecture, permissions, potential subprocessors and geographies should be understood before processing is authorised.
We choose the tool for the project, and its permissions are part of that decision
Depending on the scenario, we use Microsoft-native capabilities and, where they add value, specialist tools. Not every platform needs the same level of access or processes data in the same way.
A tool is not introduced automatically simply because we use it on other projects
If a platform requires permissions, admin consent, data access or processing by a third party, that must be understood within the project architecture and approval process.
Where the customer maintains a list of approved suppliers or tools, we can review technical alternatives within those constraints.
A technically correct change can still be the wrong change if it is executed without coordination
Permissions answer who can perform an action. Change Management answers when it should be performed, who approves it and how we validate that the outcome is correct.
Define
What is changing and why.
Assess
Impact, dependencies and risk.
Approve
Owners and maintenance window.
Execute
Controlled change.
Validate
Acceptance criteria.
Record
Outcome and evidence.
Rollback where feasible
Before sensitive changes, we assess what can be reversed, what cannot be reversed and what alternative plan exists if the outcome is not as expected.
Backup is not migration
A migration tool should not be assumed to be a backup system. If the project requires additional protection, it should be defined explicitly.
Hypercare
After cutovers or significant changes, a stabilisation phase helps resolve issues that only become visible in production.
We can integrate with the customer’s change process
ServiceNow, Jira, Azure DevOps, RFCs, CABs, maintenance windows and internal approvals can form part of execution where the organisation requires them.
Trusted access should leave enough information to reconstruct what happened
Microsoft 365, Microsoft Entra and Azure provide different audit sources. We use them alongside the project’s operational documentation.
Entra Audit Logs
They can be used to review activity involving users, groups, applications, roles and other directory objects.
Sign-in Logs
They provide information about user and application sign-ins.
Microsoft Purview Audit
It can be used to search user and administrator activities recorded across multiple Microsoft services.
Azure Activity Log
Provides visibility into events at Azure subscription level.
Tickets and change records
Project actions can be accompanied by tickets, runbooks and validation evidence.
Customer SIEM
Where the customer uses Sentinel or another platform, available logs can form part of its monitoring strategy.
The evidence required depends on the risk of the change
A minor adjustment does not necessarily require the same level of documentation as a domain cutover, a Conditional Access change or an intervention involving privileged access.
We can agree evidence, reports and records at the level of detail appropriate to the project.
If something does not behave as expected, the priority is to limit impact, understand it and communicate
Each organisation may have its own response process. Where one exists, our actions should integrate with it.
Detect
Identify anomalous behaviour.
Contain
Limit impact when required.
Inform
Escalate to the agreed contacts.
Investigate
Review logs, changes and scope.
Recover
Restore service or stabilise the environment.
Review
Document cause and actions.
Notification times, channels, owners, severity levels, SLAs and specific obligations are defined according to the service and the applicable contractual documentation.
A temporary project and an ongoing operational relationship require different controls
When MSAdvance provides recurring administration, access stops being a project exception and becomes part of an operating model that must be governed.
Granular delegation
For Microsoft 365, GDAP can provide a more granular and constrained relationship than broad delegated-administration models.
Azure Lighthouse
In Azure, Lighthouse can centralise delegated administration while retaining control over roles and scopes.
Periodic reviews
Recurring roles should continue to have a valid justification as the service changes.
Clear responsibilities
Incidents, changes, licensing, security and approvals should have defined owners.
Change Management
Recurring operations should respect the approval model agreed with the customer.
Offboarding
When the service ends, delegations, accounts and permissions should be formally reviewed.
Your organisation should not need to weaken its controls in order to work with us
During onboarding, we can review technical and operational controls defined by IT, Security, Legal, Compliance, Data Protection or Procurement.
A project does not end when the change works; it ends when unnecessary access is gone
An important part of closure is identifying which elements were created for the project and which should be retained, reduced or removed.
Accounts
We review identities created specifically to perform the work.
Roles
Temporary or expanded privileges are no longer needed once the scope closes.
Enterprise Applications
Applications introduced exclusively for the project are included in the review.
Consent grants
Application permissions should continue to serve a legitimate purpose after the project.
Temporary artefacts
Exports, working files and logs are reviewed according to their usefulness and retention requirements.
Documentation
We consolidate relevant information to support the customer’s operational continuity.
Managed services are a deliberate exception, not forgotten access
If the contracted service requires recurring access, permissions are not removed after each individual intervention because they form part of an active operational relationship.
In that case, access must be governed as part of the managed service and formally removed during offboarding.
Microsoft protects the platform; the customer retains responsibilities for data, identities and configuration
The model varies between SaaS, PaaS and IaaS, but Microsoft makes clear that the customer always retains responsibility for its data and identities.
| Area | Microsoft | Customer | MSAdvance |
|---|---|---|---|
| Physical infrastructure | Protects and operates the datacentres and physical components of the cloud service. | Selects the cloud services it uses. | Designs and configures on top of the platform within the contracted scope. |
| Data | Provides platform capabilities, availability and security according to the service. | Retains governance, classification, protection and obligations relating to the data. | Accesses or processes data only according to the service and applicable authorisations. |
| Identities | Provides Microsoft Entra and identity mechanisms. | Owns users, accounts and access decisions. | Uses or configures permissions within the authorised scope. |
| Configuration | Provides features and controls. | Defines requirements, policies and acceptable risk. | Recommends or implements the contracted configuration. |
| MSAdvance access | Provides RBAC, PIM, logs and other control mechanisms. | Authorises, governs and can remove granted access. | Uses access for the agreed purpose. |
We can help your security team understand exactly how the service will be delivered
In medium-sized and large organisations, a project may need to pass a supplier assessment before work begins. We prefer to resolve those questions before the project starts, not during a cutover.
NDA and confidentiality
Review confidentiality requirements before receiving sensitive information.
Statement of Work
Defined systems, responsibilities, deliverables and exclusions.
DPA and data flow
Where applicable, processing, purpose, tools and involved parties can be documented.
Permission matrix
Roles, scopes, applications and elevations required by phase and workload.
Tools used
Identification of Microsoft-native or third-party platforms required for the project.
Runbook and maintenance windows
Critical operations, sequence, validation and responsibilities.
Risks and mitigations
Dependencies, sensitive scenarios and measures to reduce impact.
Evidence
Logs, tickets, validation results and closure information.
Access-removal plan
Which access grants, applications or artefacts should be reviewed at the end.
Does your organisation use its own Security Questionnaire?
We can review questions relevant to the service and provide the technical information needed about the access model, tools, flows, responsibilities and operation.
Where a question requires a specific certification, insurance policy, contractual guarantee or corporate evidence, the answer should be based on verifiable documentation rather than generic claims.
We prefer to explain the limits rather than build trust through absolute claims
A Trust Center should help customers make an informed decision, not hide the differences between services.
Not every project requires Global Admin
Some may require it temporarily. Others can be completed with specific roles or read access.
Migration is not the same as backup
Copying data to a new system does not automatically replace a backup and recovery strategy.
Remote delivery is not the same as international data access
The architecture, tools and actual access location must be assessed before determining what processing takes place.
No single tool is right for every project
We select technology according to source, destination, workloads, volume and customer controls.
A log does not replace an approval
Audit tells you what happened. Change Management determines whether it should have happened.
The Trust Center does not replace the contract
The specific scope, SLA, obligations and guarantees depend on the documentation applicable to each service.
Principles aligned with Microsoft ecosystem capabilities and recommendations
These sources allow customers to verify concepts such as least privilege, PIM, GDAP, Azure Lighthouse, Microsoft Graph, auditing and shared responsibility directly.
External links are included as technical references. Microsoft product requirements, features and licensing can change over time and should be validated for each project.
Learn who we are, what credentials we hold and what projects we have delivered
Security, privacy and access when working with MSAdvance
Direct answers to common questions from IT, CISOs, Legal, Compliance and Procurement teams.
Does MSAdvance sign confidentiality agreements or NDAs?
Yes. We can sign an NDA when the customer or project requires it, including before sensitive technical information about users, architecture, domains, security, acquisitions, infrastructure or data is shared.
Does MSAdvance provide remote and global services?
Yes. MSAdvance provides a global remote service to organisations across different geographies. Access can be adapted to customer controls such as MFA, VPN, VDI, bastions, IP ranges, territorial restrictions and maintenance windows.
Is it safe to grant MSAdvance administrative access?
The level of risk depends on the specific permissions and controls. Our approach is to define access according to the task, prioritise least privilege, strong authentication and traceability, and remove permissions when they are no longer required.
Does MSAdvance need Global Administrator for Microsoft 365?
Not as a general rule. Some scenarios may require Global Administrator for specific operations, but many tasks can be performed with read access, workload-specific roles or temporary privileges.
Can we grant access through Microsoft Entra PIM?
Yes, when the tenant’s licensing and configuration support it. PIM allows a role to be eligible and activated for a limited period, and can include MFA, approval, justification and notifications.
Do you use MFA for administrative accounts?
We favour MFA for administrative identities. When we work within a customer-defined access model, we adapt to its MFA, Conditional Access and authentication policies.
Can GDAP be used with MSAdvance?
Yes, where appropriate for the relationship and service. Microsoft defines GDAP as a model for granting partners granular, least-privilege and time-bound access.
Can MSAdvance administer Azure through Azure Lighthouse?
Yes. Azure Lighthouse can be used to delegate administration of subscriptions or resource groups through defined roles and scopes. Suitability depends on the service model and scope.
Does MSAdvance use the customer’s break-glass accounts?
They are not part of normal operational access. Emergency accounts are designed for exceptional situations where normal administrative identities cannot be used and should remain under the customer’s control.
Do you need users’ passwords?
Not as a normal way of working. Modern projects use OAuth, roles, applications, APIs and authorisation mechanisms. If a legacy platform requires technical credentials, we agree with the customer how they will be provided, used and removed.
What happens if a tool needs Microsoft Graph permissions?
We review the purpose and required permissions, distinguishing between delegated and application permissions. Application permissions can operate without a signed-in user, so they require particular care.
Can the customer review the applications MSAdvance uses?
Yes. If a tool requires an enterprise application, service principal, admin consent or access to data, those elements can form part of the project’s technical review and approval.
Do you copy Microsoft 365 data to MSAdvance devices?
Our approach is to minimise unnecessary copies. Whenever a task can be performed directly on the customer’s platform or through appropriate cloud tools, we avoid creating additional exports. If an export is required, it should serve a specific purpose.
How does MSAdvance approach GDPR?
When a service involves processing personal data on behalf of the customer, responsibilities should be documented according to the applicable role. If MSAdvance acts as a processor, processing takes place within the instructions, purpose and conditions agreed with the controller.
Can MSAdvance work only from specific geographies?
If the customer sets territorial restrictions for security, data-protection or compliance reasons, we can assess them during service design and adapt delivery where technically feasible.
Can we require VPN, VDI or a bastion host?
Yes. We can work within specific corporate controls when they are compatible with the project tasks. Enterprise environments commonly use VPN, VDI, jump servers, bastions or privileged workstations for third-party access.
How do we know what changes MSAdvance has made?
Microsoft Entra, Microsoft Purview and Azure provide different activity and audit logs. The project can also include tickets, runbooks, change records and validation evidence.
Can we require every change to have a ticket?
Yes. We can adapt execution to the customer’s Change Management process, including ServiceNow, Jira, Azure DevOps, CAB, RFCs, maintenance windows and approvals.
Do you prepare rollback plans before major changes?
For sensitive changes, we assess what can be reversed, what dependencies exist and what alternative is available if the outcome is not as expected. Not every change is technically reversible, so this must be assessed case by case.
Does a migration tool count as a backup?
It should not be assumed to. Migration and backup serve different purposes. If a project requires a specific protection or recovery layer, it should be defined in scope.
Do you use third-party tools for migrations?
Depending on the scenario, we may use Microsoft-native capabilities or specialist tools such as Quest, AvePoint, ShareGate or BitTitan. Selection depends on source, destination, workloads, volume and requirements.
Can we restrict which tools are allowed?
Yes. If the organisation maintains a catalogue of approved tools or providers, it should be identified during discovery so compatible alternatives can be assessed.
What happens to access when a project ends?
Closure includes reviewing accounts, roles, enterprise applications, service principals, consent grants and other access created specifically to deliver the project.
What if MSAdvance provides an ongoing managed service?
In a managed service, recurring access is part of the active service. In that case, it should be governed throughout the relationship and formally removed during offboarding.
Can you complete supplier security questionnaires?
We can review and answer technical questions relevant to the service and provide information about access, tools, architecture, permissions, operations and processing where applicable.
Can you work with ISO 27001, ENS or internal-policy requirements?
We can adapt the project to technical and operational requirements derived from ISO 27001, ENS, GDPR or other customer frameworks and policies. Working to those requirements does not imply a corporate certification unless that certification has been expressly evidenced.
Who ultimately controls access to the tenant?
The tenant belongs to the customer, and the customer retains governance of identities and authorisations. Permissions granted to MSAdvance can be reviewed, changed or removed according to the agreed model.
We can design the project around your security, privacy and governance requirements
If your organisation requires an NDA, Security Questionnaire, PIM, VPN, VDI, GDAP, Azure Lighthouse, geographic restrictions, approved tools, formal Change Management or a specific supplier-onboarding process, tell us from the outset. The delivery model should reflect the risk profile and the reality of your business.
