Secure Defence Collaboration – A Practical Guide for the UK Defence Supply Chain

Defence programmes depend on people from different organisations being able to communicate, share information and make decisions together. That collaboration has to remain usable at delivery pace while preserving the controls, evidence and accountability expected across the UK defence supply chain.

This guide explains what secure defence collaboration means in practice, how it differs from secure file sharing, what buyers should expect from a managed collaboration environment and how the platform, endpoints, service operations and organisational responsibilities fit together.

Updated Q3 2026 | Built around current GOV.UK, Digital MOD.UK and NCSC guidance as of 4 August 2026

Overview

If you only remember six things from this guide:

• Secure defence collaboration is an operating model for controlled joint working. A platform is one part of that model; identity, endpoints, information handling, monitoring, support and governance determine whether it remains secure in practice.
• Begin with the contract, Security Aspects Letter where applicable, information classification, handling instructions, participants and working pattern. Product selection comes after the required boundary is understood.
• OFFICIAL-SENSITIVE remains within the OFFICIAL classification tier, but it requires tighter need-to-know handling and any contract-specific requirements take precedence over general platform claims.
• CSMv4 and Defence Standard 05-138 assess broader organisational cyber resilience. A secure collaboration environment can support controls and evidence, but it does not make the supplier compliant or certified by itself.
• The endpoint matters as much as the cloud workspace. Strong tenant settings cannot protect information that is routinely accessed from unmanaged, vulnerable or shared devices.
• Secure defence collaboration is a defence use case, rather than a requirement for every suitable platform to be defence-only. A well-designed managed environment can support other regulated organisations while being configured and evidenced for defence delivery.

Introduction

A modern defence programme may involve an Authority, one or more prime contractors, specialist SMEs, engineering partners, consultants, software providers, manufacturers and external support teams. The people involved may work from different locations, use different corporate systems and join or leave at different stages. Drawings, plans, commercial material, meeting records, technical evidence and operational decisions move between them throughout the programme.

The collaboration problem is therefore wider than sending a protected file. Teams need to co-author documents, hold meetings, exchange email, manage actions, review designs, invite external users, preserve records and respond quickly when access or programme circumstances change. Each interaction creates a security and assurance decision, even when the user experiences it as an ordinary piece of work.

Secure defence collaboration provides a controlled environment for that activity. It gives programme teams a usable route for working across organisational boundaries while giving information owners, security teams and delivery leaders a clearer view of who has access, which devices are trusted, where information is held, how activity is monitored and how the service is maintained through life.

The phrase can create a positioning trap. It may sound as though the underlying technology must be exclusive to defence. In practice, many of the same design principles apply in government, critical national infrastructure and other regulated sectors. The defence context adds specific contractual, assurance, information-handling and connectivity requirements. The capability can remain broader than the market-specific use case.

What is secure defence collaboration?

Secure defence collaboration is a managed way for authorised people and organisations to communicate, share information and work together in support of defence delivery, within a defined security and assurance boundary.

That boundary usually includes the users, identities, devices, applications, workspaces, information flows, configuration, monitoring, support processes and supplier responsibilities involved in the work. It should be possible to explain what sits inside the boundary, what remains outside it and how information is allowed to cross between the two.

A defence context, rather than a defence-only product category

A platform does not need to be limited exclusively to defence customers to support secure defence collaboration. It does need a clearly defined deployment model, operating boundary and evidence set that are suitable for the defence requirement in question. The same managed service may also support government, CNI, manufacturing, research or other regulated organisations through different customer contexts and configurations.

This distinction matters for buyers and providers. Buyers should avoid assuming that the word “defence” proves suitability. Providers should avoid narrowing a capable regulated-sector service merely to own a search phrase. The meaningful questions concern scope, handling level, technical controls, operational management, contractual alignment and evidence.

Why defence collaboration needs a distinct operating model

Collaboration in defence frequently combines sensitive information, distributed suppliers, changing programme teams and formal assurance expectations. The environment must support day-to-day productivity while remaining defensible when an Authority, prime, assessor, auditor or incident investigator asks how the work is controlled.

The work crosses organisational boundaries

A defence programme rarely sits wholly inside one corporate estate. External identities, partner devices, short-term specialists and subcontractors are normal parts of delivery. Traditional internal access assumptions become weaker as soon as users and systems belong to different organisations.

The information changes as the programme develops

A document may begin as routine project material and become more sensitive as technical detail, vulnerabilities, operational context or aggregated information are added. Collaboration controls need to support classification, marking, access changes and information-owner decisions throughout the lifecycle rather than relying on a static label applied at the start.

The approved route has to compete with convenient alternatives

Users will choose the quickest workable route when an approved environment is difficult to access or poorly matched to their tasks. Personal email, consumer file sharing, unmanaged messaging and local copies often appear because the legitimate delivery need has not disappeared. A secure collaboration service therefore has to reduce workarounds through usable tools, clear guidance and responsive support.

Evidence is part of the service outcome

Defence suppliers are often asked to show how controls operate, not simply state that they exist. Access reviews, configuration records, logs, monitoring outputs, incident processes, patch status, onboarding records and service reports contribute to that evidence. A platform that is technically capable but operationally opaque leaves the supplier with an avoidable assurance gap.

Start with the contract, information and working pattern

Secure defence collaboration should begin with the requirement rather than a comparison of product features. The contract and its supporting security information establish the context in which a service will be used. A supplier needs to understand what information is involved, who owns it, which organisations will participate and which activities the environment must support.

Relevant inputs may include the contract, DEFCONs, the assigned Cyber Risk Profile, a Risk Assessment Reference, a Security Aspects Letter, handling instructions, data-protection requirements, export-control constraints, programme security procedures and prime-contractor requirements. Where different sources appear to conflict, the organisation should resolve the position with the relevant Authority, prime or information owner before relying on a general interpretation.

Map the real information flow

A useful scope exercise follows representative programme artefacts from creation to disposal. For example: who creates a technical drawing, where it is stored, who reviews it, whether it is downloaded, how comments are captured, which external parties receive it, how revisions are controlled and what happens when a supplier leaves. This exposes the points where controls can weaken or where people are likely to improvise.

Understand the participants

The collaboration model should identify employees, contractors, customer users, prime-contractor users, suppliers, guests, service administrators and support personnel. Each group may require a different identity route, approval process, device standard, permission model, monitoring level and offboarding procedure.

Define the required activities

Some teams need only controlled document exchange. Others need email, meetings, co-authoring, workflow, secure internet access, printing, mobile access, specialist applications or connectivity to customer services. The required activities determine the architecture and service boundary. They also prevent a narrow file-sharing tool from being selected for a broader operational need.

Define the secure collaboration boundary

The collaboration boundary is the clearest way to explain what the service controls. It turns a broad security claim into a practical model that can be designed, operated and assured. The boundary should be understandable to programme users as well as cyber specialists.

Boundary area	Questions to resolve	Typical evidence
People and identities	Who can join, who approves access, how roles change and how access is removed?	Onboarding records, identity configuration, role assignments, access reviews and leaver records.
Devices and endpoints	Which devices may access the service, what posture is required and who manages compliance?	Asset records, configuration baselines, compliance reports, patch and vulnerability status.
Workspaces and data	Where is information held, how are permissions structured and how is sharing controlled?	Workspace ownership, permission records, labels, sharing policies, retention and audit data.
Applications and connectivity	Which collaboration functions, integrations, internet services or customer networks are available?	Architecture diagrams, approved-service lists, interface controls and connection agreements.
Security operations	What is logged, monitored, investigated and escalated?	Log coverage, alert records, incident procedures, investigation records and response exercises.
Service operations	Who supports the service, manages change, restores data and reports performance?	Service catalogue, change records, backup tests, service reports, SLAs and continual-improvement actions.

The strongest boundaries are explicit about shared responsibility. A managed provider may operate the tenant, endpoints and monitoring, while the customer retains responsibility for information ownership, user approvals, local policy, contract interpretation and the behaviour of its people. Ambiguity at that interface is a common source of risk.

The six layers of secure defence collaboration

A useful operating model connects six layers. Weakness in any one layer can undermine the rest of the service, particularly when the work spans several organisations.

1. Identity and participant lifecycle

Every user should have an attributable identity, an approved reason for access and permissions aligned to their role. Multi-factor authentication, privileged-access controls, sponsor approval, periodic review and timely offboarding reduce the risk created by shared accounts, dormant guests and excessive access. The model should handle joiners, movers and leavers across partner organisations rather than assuming all users are employees of one company.

2. Endpoint security and device posture

The endpoint is where users view, edit, download and sometimes print information. Device ownership, configuration, encryption, malware protection, patching, vulnerability management, local storage, removable media and administrative privilege all affect the real security of the collaboration environment. Conditional access and device-compliance decisions are most useful when backed by active endpoint management and clear exception handling.

3. Collaboration and information controls

Workspaces need clear ownership, purposeful membership and permissions that reflect programme structure. Information protection may include classification labels, restricted sharing, version control, retention, data-loss prevention, controlled external access and audit. The design should preserve the ability to work productively while reducing uncontrolled copies and unrecorded routes.

4. Monitoring, detection and incident response

Logging provides the record; monitoring turns it into an operational control. The service should be able to identify suspicious access, unusual sharing, malware, risky sign-ins, privilege changes and other events relevant to the threat model. Alerts need an owner, an investigation route, defined escalation and connection to the customer’s own incident responsibilities, including any contractual reporting duties.

5. Service management and through-life control

Secure configuration can drift through routine change. New users, licences, features, integrations, suppliers and programme requirements all alter the environment. Change management, support, capacity, backup, recovery, vulnerability handling, service reporting and continual improvement keep the service aligned with its security intent. ISO-backed service management can strengthen confidence where the certification scope is clearly explained.

6. Governance, assurance and evidence

The organisation still needs accountable owners, policies, risk decisions, contract records, user guidance and evidence that the environment is used correctly. The provider’s evidence should connect with the customer’s wider assurance position rather than sit as an isolated technical pack. Good evidence is current, traceable and generated through normal operation.

Secure collaboration, file sharing and MOD connectivity

These terms are often used together, but they describe different capabilities. Buyers should separate them before comparing services.

Secure file sharing

Secure file sharing concentrates on controlled upload, download or access to documents. It can be appropriate for defined exchanges, disclosure exercises or one-way transfer. It may not provide the wider communication, co-authoring, meeting, endpoint, service-management and monitoring capabilities needed for ongoing programme delivery.

Secure collaboration

Secure collaboration supports continuing joint work. It may include shared workspaces, email, meetings, document co-authoring, task management, controlled guest access, endpoint protection, monitoring and support. The value comes from the way these capabilities operate together inside a governed boundary.

Access to MOD email, networks or services

A secure collaboration environment does not automatically provide access to r.mil.uk email, the Restricted LAN Interconnect, MOD Core Network, DEFNet, MODCloud or other Defence services. These are separate connectivity and service requirements with their own eligibility, design, contractual and assurance considerations. Some managed offerings include specific connectivity profiles; others operate as controlled internet-based workspaces. Buyers should confirm precisely what is included rather than infer connectivity from the phrase “secure defence collaboration”.

Above-OFFICIAL environments

This guide primarily addresses collaboration at OFFICIAL, including OFFICIAL-SENSITIVE. Work above OFFICIAL may require materially different architecture, connectivity, personnel, facilities, information controls and assurance. It should be treated as a separate requirement rather than assumed to be a higher setting on the same service.

Handling OFFICIAL and OFFICIAL-SENSITIVE information

The Government Security Classifications Policy uses three classification tiers: OFFICIAL, SECRET and TOP SECRET. The -SENSITIVE marking is applied within OFFICIAL where a compromise is likely to cause moderate damage and additional control is needed. It reinforces the need-to-know principle; it is not a separate fourth classification tier.

For defence collaboration, the practical handling position should be established from the contract, the information owner, the Security Aspects Letter where one applies, relevant Industry Security Notices and local policy. A platform description such as “suitable for OFFICIAL-SENSITIVE” cannot override a contract-specific restriction or make every information flow acceptable.

Need-to-know has to remain visible in the workspace

A user may be authorised to work on a programme without needing access to every team, folder or document. Workspace design should make narrower access practical. Broad groups, inherited permissions and uncontrolled guest membership can weaken the intended handling position even when every user belongs to a legitimate organisation.

Marking and handling instructions need operational support

Users need a clear method for applying the appropriate classification, sensitivity and handling instructions to documents and email. Technology can support this through labels, policies and prompts, but the information creator and owner still need to understand the meaning of the marking and the permitted audience.

Electronic movement is a controlled decision

Sending, downloading or transferring OFFICIAL-SENSITIVE material changes where the information is held and who can control it. The approved route should enforce recipient checks, marking, encryption and any applicable dissemination restrictions. Where the data leaves the managed boundary, the organisation should understand what protections continue to apply and what evidence remains available.

Microsoft 365 in a secure defence environment

Microsoft 365 provides extensive capabilities for identity, email, meetings, document collaboration, device management, information protection, audit and security operations. Its suitability for a defence requirement depends on how those capabilities are licensed, configured, integrated, operated and evidenced.

A standard tenant and a managed secure environment can therefore present very different risk positions even when both use familiar Microsoft applications. The decisive factors include the security baseline, administrative model, endpoint controls, external sharing, monitoring, incident response, change management, support model and the information the environment is expected to handle.

Configuration is part of the security architecture

Identity policies, conditional access, guest settings, sharing defaults, audit retention, application permissions and administrative roles shape the boundary. A secure design should record why significant settings exist, who can change them and how changes are reviewed. This provides a stronger basis for assurance than a one-time checklist against a generic configuration guide.

Licensing affects the available control set

Different Microsoft 365 licence plans expose different identity, endpoint, information-protection, monitoring and compliance capabilities. Buyers should confirm which controls are included in the proposed service, which are optional and which responsibilities are fulfilled through separate tools or managed processes.

Managed operation is where the design is sustained

Security value depends on routine operation: investigating alerts, reviewing access, remediating vulnerabilities, managing devices, controlling change, supporting users and producing evidence. A well-configured tenant that is weakly operated will drift away from its intended assurance position.

How CSMv4, Def Stan 05-138 and DCC relate to collaboration

The MOD Cyber Security Model is a risk-based and proportionate approach for building cyber security into the defence supply chain. Defence Standard 05-138 Issue 4 defines the Cyber Risk Profiles and associated minimum controls. Its scope is the supplier’s overarching corporate or enterprise environment, including the systems, processes, procedures and data needed to protect contracted outputs and business-critical functions.

That organisational scope is important. A secure collaboration platform may implement or support controls around identity, endpoints, configuration, monitoring, incident management, resilience and suppliers. It cannot, on its own, demonstrate the supplier’s governance, wider assets, business continuity, people, subcontractors, corporate services or full control environment.

A platform supports compliance activity; it does not confer compliance

Useful platform evidence may include access reviews, device-compliance reports, vulnerability and patch status, configuration records, monitoring outputs, incident records, service reports and recovery tests. The supplier still has to connect that evidence to its applicable controls, policies, risk decisions and broader organisational scope.

Defence Cyber Certification is organisation-wide

Defence Cyber Certification provides independent organisation-level evidence aligned to the four CSMv4 levels. MOD has asked industry partners to achieve DCC Level 0 by 31 December 2026. A managed collaboration environment can help an organisation operate and evidence relevant controls, but the certification belongs to the organisation and remains dependent on the full assessment scope.

Flow-down includes the way subcontractors collaborate

Where suppliers subcontract work, CSMv4 flow-down can extend cyber requirements into lower tiers. The collaboration model should support that reality through controlled onboarding, defined workspaces, appropriate device and access requirements, documented responsibilities and timely removal. A subcontractor should not be brought into sensitive delivery through an informal sharing route simply because the commercial relationship is small.

Secure by Design and through-life assurance

Digital MOD.UK states that capabilities and services handling Defence data must follow Secure by Design, including supplier-delivered capabilities. Secure collaboration should therefore be considered as part of the programme’s lifecycle, architecture, supply chain and assurance model rather than introduced only when teams need to exchange files.

Understand the context before selecting the pattern

The service should be designed around the capability, users, information, threats, dependencies and operational constraints. Existing secure services and patterns may reduce delivery risk where they fit the requirement, but reuse still needs a clear understanding of scope and residual responsibility.

Plan assurance and evidence alongside delivery

Architecture decisions, configuration, testing, onboarding, migration, training and operational readiness all create evidence. Capturing that evidence as the service is designed and introduced is more reliable than reconstructing the rationale before an assessment or Authority review.

Keep the assurance position current

New features, suppliers, integrations, locations, data types and working practices can invalidate earlier assumptions. The operating model should define which changes require security review, who accepts residual risk and how evidence is updated. Through-life assurance is especially important for long programmes where the original design team may no longer be present.

Working across primes, SMEs and subcontractors

A secure collaboration environment should reduce the practical imbalance between organisations of different sizes. A prime may have extensive internal security capability, while a specialist SME may contribute critical intellectual property through a small team. The shared environment should give both parties a clear route for participating without requiring uncontrolled duplication into separate corporate systems.

Onboarding should establish trust and responsibility

The process should confirm the user, organisation, sponsor, role, required workspace, device route, permitted activities and expected end date. It should also make the user’s handling responsibilities understandable. A successful sign-in is only one part of onboarding.

Workspace structure should reflect programme relationships

A single broad team can be easy to create and difficult to govern. Workspaces should reflect genuine delivery groups, information boundaries and ownership. Sensitive commercial, security or technical material may need narrower areas even when the wider programme team is authorised to collaborate.

Supplier exit needs to be designed from the start

When a work package ends, the organisation should be able to remove identities and devices, close access, preserve required records, return or dispose of information and confirm whether local copies remain. Exit clauses and data-handling arrangements are easier to enforce when the service already provides clear ownership and audit trails.

Controlled data movement and external sharing

Collaboration environments are valuable because they keep people working inside a governed space. Programmes will still need to move information in and out: importing customer material, sharing approved outputs, exchanging data with specialist applications, sending email, printing or moving records at contract end. These routes should be designed rather than treated as exceptions.

Make approved routes obvious

Users should know how to share with another team, invite an external participant, send a large file, export an approved document or request a new integration. Where the process is unclear, people will invent a route that may lose marking, encryption, audit or control.

Apply proportionate checks at the boundary

Useful controls can include recipient validation, sensitivity labels, sharing expiry, restricted download, malware scanning, data-loss prevention, approval workflows and audit. The appropriate combination depends on the information, recipient, task and contract. A control that blocks every legitimate exchange may simply move the risk elsewhere.

Retain provenance and accountability

The organisation should be able to identify who shared information, what was shared, with whom, under which authority and whether access remains active. This supports incident response, contract management, records management and the information owner’s ability to review the decision later.

How to evaluate a secure defence collaboration platform

A credible evaluation looks beyond feature lists and generic statements about encryption or compliance. It tests whether the proposed environment can support the required work and whether the provider can explain the full technical and operational boundary.

• What information classifications, markings and handling contexts is the service designed to support, and what qualifications or exclusions apply?
• Which organisations, user types and device models can participate?
• How are identities verified, approved, reviewed and removed?
• Which endpoint controls are included, who manages them and how are exceptions handled?
• How are workspaces, permissions, external sharing, labels, downloads and retention governed?
• What audit data is available, how long is it retained and who actively monitors it?
• How are alerts investigated and connected to customer incident and MOD reporting responsibilities?
• Which security, service-management and quality certifications cover the provider or service, and what is the exact certification scope?
• How are changes, vulnerabilities, patches, backups, recovery and service continuity managed and evidenced?
• What data-residency, sovereignty, personnel and supply-chain arrangements apply?
• Does the service include any MOD email or network connectivity, and under what conditions?
• How does the service support CSMv4 and DCC evidence without overstating what the platform can achieve?
• How are onboarding, migration, training, support, contract exit and data return or disposal handled?
• What remains the customer’s responsibility?

A strong provider should answer these questions precisely and be comfortable describing limitations. Vague assurances create work for the buyer later, particularly when a programme reaches mobilisation, assessment or incident response.

The route from requirement to live service

1. Establish the delivery context

Collect the contract, relevant security conditions, classification and handling requirements, participant groups, required activities, programme timescales and existing systems. Identify the information owner, service owner, risk owner and decision route.

2. Design the boundary and responsibility model

Define users, devices, workspaces, sharing routes, connectivity, administration, monitoring, support and evidence. Record which controls are provided by the service and which remain with the customer or another supplier.

3. Configure, test and prepare evidence

Apply the security baseline, test representative user journeys, confirm external access, validate logging and alerts, test recovery, document exceptions and create the initial evidence set. Include security and usability testing; both affect whether the approved route will be followed.

4. Onboard people and information deliberately

Verify identities, enrol devices, grant role-based access, migrate required information, apply labels and retention, train users in their real tasks and confirm how they obtain help. Avoid bulk migration of redundant or poorly owned data merely because storage is available.

5. Operate, review and improve

Review access, device health, vulnerabilities, alerts, incidents, service performance, supplier changes and user feedback. Reassess the boundary when the programme, information or threat changes, and retain evidence through the service lifecycle.

Common mistakes

Buying a secure file-sharing tool for a broader collaboration need

The programme later adds email, meetings, co-authoring, guest users and local downloads through separate routes. The result is a fragmented operating model with inconsistent controls and evidence.

Treating the tenant as the whole boundary

The organisation secures cloud settings while leaving endpoints, identities, printers, local storage, support processes or external users weakly governed.

Assuming encryption settles the risk

Encryption protects against particular threats. It does not decide whether the recipient should have access, prevent excessive permissions, remove a leaver or investigate suspicious activity.

Taking an OFFICIAL-SENSITIVE claim as universal approval

The contract, Security Aspects Letter, information owner and specific information flow still determine whether use is appropriate. Marketing language cannot replace that decision.

Presenting a platform as DCC or CSMv4 compliance

This obscures the organisation-wide scope of the assurance model and can create false confidence. The platform should be described as supporting relevant controls and evidence.

Leaving external users permanently active

Guests and contractors accumulate because their access was approved for a project but never given an owner or review date.

Collecting logs without an operating response

Audit data is retained, but no one reviews alerts, investigates events or knows how the provider and customer will coordinate an incident.

Ignoring user experience

Slow onboarding, limited functionality or confusing sharing routes drive users towards unauthorised alternatives. Security controls need an operating path that people can realistically follow.

Discovering connectivity assumptions during mobilisation

The buyer expects r.mil.uk or MOD service access while the proposed workspace is internet-only, or assumes a network connection will automatically permit every required service.

Treating exit as an administrative afterthought

The programme reaches completion without a clear route for record retention, data return, deletion, account closure, device handling and supplier confirmation.

Choosing a secure collaboration partner

The provider needs to understand more than collaboration software. Defence delivery brings together cloud architecture, identity, endpoint management, service operations, information handling, assurance, supplier relationships and contract context. The partner should be able to connect those areas without claiming ownership of decisions that remain with the customer or Authority.

Useful evidence includes experience in security-conscious environments, clear architecture and service documentation, independently certified management systems within stated scopes, trained and appropriately cleared personnel where required, transparent supply-chain arrangements, operational reporting and a willingness to support assurance conversations throughout the service lifecycle.

The commercial model also matters. Buyers should understand what is included in the core service, which capabilities require additional licensing or bespoke delivery, how user and device changes are handled, what support is available and how the organisation can exit without losing access to required information or evidence.

How Logiq supports secure defence collaboration

Logiq supports defence suppliers and programme teams with both the secure environment and the assurance context around it. Our work spans secure collaboration, Secure by Design, CSMv4 and DCC readiness, security architecture, risk management and ongoing cyber assurance.

DISX Secure Collaboration is a managed, sovereign Microsoft 365 environment designed for organisations operating in regulated, policy-constrained and high-assurance contexts, including defence, government and critical national infrastructure. It establishes a defined collaboration boundary across identity, device posture, access policy, configuration, monitoring and service operations.

For defence delivery, DISX can support communication, document collaboration and controlled programme working involving OFFICIAL and OFFICIAL-SENSITIVE information, subject to the applicable contract, information-owner decisions and handling requirements. The service includes managed security and operational controls intended to provide a stable, evidence-friendly environment rather than leaving customers to assemble and maintain separate components.

DISX remains applicable beyond defence. The underlying need – a controlled, managed environment for sensitive collaboration – is shared by government, CNI and other regulated organisations. The deployment context, information, assurance requirements and customer responsibilities determine how the service is used.

Where the requirement extends above OFFICIAL or calls for deliberately isolated operations, Logiq can also help organisations assess a separate operating model rather than forcing the work into an unsuitable collaboration pattern.

Frequently Asked Questions

What is secure defence collaboration?

Secure defence collaboration is a managed way for authorised people and organisations to communicate, share information and work together for defence delivery within a defined security and assurance boundary. It combines collaboration tools with identity, endpoint, information, monitoring, governance and service-management controls.

Is secure defence collaboration the same as secure file sharing?

No. Secure file sharing focuses mainly on transferring or granting access to files. Secure collaboration supports continuing work such as email, meetings, co-authoring, shared workspaces, external participation, endpoint control, monitoring and through-life support.

Can Microsoft 365 be used for secure defence collaboration?

Microsoft 365 provides many of the required capabilities. Suitability depends on the licence, tenant configuration, endpoint controls, operational management, information-handling requirements, monitoring, evidence and the applicable contract. A default tenant and a managed secure environment should not be treated as equivalent.

Does a secure collaboration platform make an organisation CSMv4 compliant?

No. CSMv4 and Defence Standard 05-138 address broader organisational resilience. A platform can implement and evidence relevant controls, while the supplier remains responsible for its full scope, governance, people, processes, suppliers and certification or assurance activity.

Does DISX guarantee Defence Cyber Certification?

No. DCC is an organisation-wide certification. DISX can support technical and operational controls and provide useful evidence, but the organisation must meet and demonstrate the complete requirements for its chosen DCC level.

What is OFFICIAL-SENSITIVE?

OFFICIAL-SENSITIVE is a marking within the OFFICIAL classification tier for information where compromise is likely to cause moderate damage and tighter need-to-know handling is required. The contract, information owner, Security Aspects Letter and relevant guidance determine the controls for a specific use.

Does secure defence collaboration require an RLI or MOD network connection?

Not always. A controlled collaboration workspace may operate over the internet, while some requirements need r.mil.uk email, RLI or access to particular MOD services. Connectivity should be specified separately and confirmed as part of the proposed service.

Can suppliers and external guests use the same environment?

Yes, where the service supports controlled external participation. Users should have attributable identities, approved sponsors, suitable device routes, role-based access, review dates and defined offboarding. External access should be designed into the model rather than treated as a permanent exception.

Is secure defence collaboration only relevant to defence?

The defence use case has specific contractual, classification, assurance and connectivity considerations. The underlying secure collaboration capability can also support government, CNI and other regulated organisations when the boundary and controls are appropriate to their context.

Do endpoints need to be managed?

The organisation needs confidence in the devices that access sensitive information. The exact model can vary, but unmanaged or poorly controlled endpoints weaken identity, data-protection and monitoring controls. Buyers should establish who owns, configures, patches and monitors each permitted device type.

What happens when a programme ends?

The exit plan should remove users and devices, close external access, preserve required records and evidence, return or transfer information where authorised, dispose of data appropriately and confirm that contractual retention and security duties continue to be met.

How quickly can a secure collaboration environment be deployed?

Timescales depend on the number of users and devices, required integrations, information migration, connectivity, assurance activity and customer decision-making. A pre-configured managed service can reduce technical build time, but secure onboarding and scope decisions should not be skipped to create an artificial launch date.ed with clear architecture, risk management and assurance.

Who accepts residual cyber risk?

The accountable risk owner within the organisation accepts residual risk according to the relevant governance model. Consultants, auditors and assessors can provide evidence and advice, but they do not remove the organisation’s accountability for the decision.

Glossary

Term	Meaning in this guide
Collaboration boundary	The people, identities, devices, applications, workspaces, data flows, controls, operations and responsibilities governed as part of the service.
CSMv4	Cyber Security Model version 4: MOD’s risk-based approach for building cyber security into the defence supply chain.
Cyber Risk Profile	The level generated through the CSM risk assessment that determines the applicable Def Stan 05-138 control requirements.
DCC	Defence Cyber Certification: independent organisation-wide certification aligned to the four CSMv4 levels.
Def Stan 05-138	The Defence Standard defining Cyber Risk Profiles and minimum cyber security controls for defence suppliers.
DEFCON 658	The Defence Condition that sets contractual terms for the Cyber Security Model, including supplier and flow-down responsibilities.
Endpoint	A device used to access the collaboration environment, such as a managed laptop, desktop, mobile device or virtual desktop.
GSCP	Government Security Classifications Policy, which defines the OFFICIAL, SECRET and TOP SECRET tiers and associated markings and handling principles.
MODII	MOD Identifiable Information: information used in relation to MOD activity and subject to relevant contractual and security requirements.
OFFICIAL-SENSITIVE	A marking within OFFICIAL used where compromise is likely to cause moderate damage and tighter need-to-know handling is required.
RLI	Restricted LAN Interconnect: a route used by eligible organisations for access to specified MOD services. It is distinct from a general collaboration workspace.
SAL	Security Aspects Letter: a contract-specific security document identifying classified assets and applicable security conditions where required.
SAQ	Supplier Assurance Questionnaire completed against the applicable Cyber Risk Profile through the Supplier Cyber Protection Service.
SCPS	Supplier Cyber Protection Service: the online service used for CSMv4 risk assessments and supplier assurance activity.
Secure by Design	MOD’s lifecycle approach for placing cyber security at the heart of capabilities and services, including supplier-delivered capabilities.
Sovereign service	A term that should be qualified by the provider, covering matters such as hosting location, operational control, personnel, legal jurisdiction and supply-chain dependencies.

---

How We Can Help

Secure defence collaboration works when the security requirement, platform architecture, endpoint model, service operations and customer responsibilities are designed as one system. Logiq helps organisations establish that model and maintain it through delivery.

Our support can include discovery and requirements definition, secure collaboration architecture, DISX deployment, user and device onboarding, information migration, CSMv4 and DCC readiness, Secure by Design support, security assurance and through-life managed service operation.

Whether you need a dedicated environment alongside your existing estate, a primary managed workspace for regulated work or advice on a requirement that extends above OFFICIAL, we can help translate the programme context into a practical and defensible route forward.

Talk to our secure solutions team about your collaboration requirement.

---

Related reading

• DISX Secure Collaboration
• What is secure collaboration?
• Defence Supply Chain Cyber Security – A Practical Guide for UK Suppliers
• MOD Secure by Design – A Practical Guide for Defence and Government
• High-Assurance Cyber Security – Principles, Architecture and Delivery
• Choosing the Right Secure Collaboration Platform
• OFFICIAL vs OFFICIAL-SENSITIVE: What Defence Suppliers Need to Know
• Def Stan 05-138 Explained
• What is DEFCON 658?
• Secure Collaboration and the Modern Defence Supply Chain
• DISX Isolate

Source and citations

• MOD Cyber Security Model – Current CSMv4 process, Def Stan relationship, SAQ, flow-down and DCC context.
• Defence Standard 05-138 Issue 4 – Cyber Risk Profiles, organisational scope and minimum control requirements.
• Government Security Classifications Policy – Classification tiers, -SENSITIVE marking and handling principles.
• Guidance 1.1 – Working at OFFICIAL – Practical handling guidance for OFFICIAL and OFFICIAL-SENSITIVE information.
• Industry Security Notices collection – Current MOD notices, including DCC assurance, SALs, cloud controls and electronic movement.
• ISN 2024/06 – Cloud security control requirements for handling OFFICIAL MOD information – Minimum cloud control requirements for Defence suppliers handling OFFICIAL, including OFFICIAL-SENSITIVE, MOD information.
• ISN 2023/04 – Electronic movement of OFFICIAL-SENSITIVE MOD Identifiable Information – Need-to-know, marking and electronic transmission considerations.
• Digital MOD.UK – Secure by Design – Lifecycle activities, supply-chain management, assurance and through-life security.
• Digital MOD.UK – What is Secure by Design? – Applicability to capabilities and services that handle Defence data, including supplier-delivered capabilities.
• NCSC Cloud Security Principles – Cloud selection, shared responsibility, identity, user management, supply chain and audit.
• NCSC Supply Chain Security Guidance – Understanding, controlling and continually improving supply-chain security.
• NCSC Logging and Monitoring – Relationship between logs, monitoring, investigation and incident response.
• MOD Defence Cyber Certification – one-year update – Organisation-wide certification context and Level 0 objective for 31 December 2026.

---

Important note: This guide is intended as an overview to help organisations understand the principles and practical considerations of this topic. It is not a substitute for official guidance, contractual requirements or professional advice. Always refer to the latest official guidance and the specific requirements of your organisation, customer or contract before making implementation or compliance decisions. Last reviewed: 4 August 2026.