What are the best practices for the use of external systems?

How to decide which external systems are allowed

The first control is classification, not tooling. Decide which external systems are approved for organisational data, what data classes they may handle, and whether they are allowed only in specific business contexts or on managed devices. If the approval boundary is vague, users will route sensitive data through whichever app is easiest, which defeats the point of the policy.

A usable rule set should distinguish between business-approved systems, personal accounts, unmanaged endpoints, and removable media. That distinction matters because each of those paths changes who can access the data later, where it is stored, and whether the organisation can enforce retention, deletion, logging, or remote revocation. The policy should be written so users can tell, in practice, which use is permitted and which is not.

For baseline control design, NIST SP 800-53 Guide is useful for mapping the policy to access control, auditability, configuration, and media protection expectations. It is especially helpful when you need to turn a high-level “approved systems only” rule into enforceable control families.

What protections matter when external systems handle organisational data

Once a system is approved, the next question is whether it can protect the data at the same level the organisation expects internally. Encryption, access controls, session controls, and device protections are not optional extras when external systems may store or process business information. They are the practical minimum for reducing exposure if the account, endpoint, or cloud tenant is later compromised.

Encryption should be treated as a transport and storage requirement, not a checkbox. Access control should cover both who can use the system and what they can do with data after they get in. If the external system cannot support those protections, the safer decision is to restrict the data type, limit the use case, or disallow the system for that class of information.

Where the organisation is evaluating a broader security baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control catalog behind those expectations, while NIST Cybersecurity Framework 2.0 gives a governance-to-protection lens for deciding how external-system use fits into the wider security program.

How to control leakage, exceptions, and user behaviour

Best practice is not only about selecting the right system, it is about limiting the ways data can escape control. Personal cloud storage, unmanaged devices, and removable media are common leakage paths because they bypass central oversight and make later recovery difficult. If users can copy data into uncontrolled locations, the approved-system model becomes advisory instead of protective.

Exception handling needs a clear owner and a review cadence. Temporary access to an unapproved system, or a one-off need to move data through a less capable environment, should be logged, time bound, and revisited. If exceptions become routine, that is usually a sign the approved-tool set is incomplete or the policy is too strict for the actual workflow.

User education matters most where convenience pressures are highest. People need to understand that “easy to share” is not the same as “safe to share”, and that unmanaged tools create retention, deletion, and disclosure problems the organisation may not be able to reverse after the fact. The more sensitive the data, the less acceptable informal workarounds become.

Practitioner Guidance

What to verify: Confirm that the approved external system can enforce the same data handling limits the policy assumes, including encryption, access restriction, and revocation or wipe capability where applicable. If it cannot, narrow the data class rather than relying on user discipline alone.

Decision rule: If a system cannot be monitored, controlled, or cleaned up after loss of access, treat it as unsuitable for sensitive organisational data even if it is popular with users. Convenience is not a compensating control.

What practitioners underestimate: The biggest failure mode is not a single prohibited upload, it is the slow normalisation of exceptions. Once unmanaged tools become part of routine work, data leakage risk becomes structural rather than accidental.

Practitioner takeaway: The real test is whether the organisation can still govern the data after it leaves its own environment. If it cannot, the external system should be limited, tightly wrapped with controls, or excluded from sensitive use cases.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should security teams use IAST and RASP in NHI governance?
• Should organisations prioritise external exposure or internal credential governance first?
• How can organizations manage unauthorized agents in their systems?