What security controls should be confirmed before cloud migration?

Before cloud migration, security controls should be confirmed as documented, tested and assigned to a named owner. The review should cover not only the technical platform, but also the data being moved, the people and devices using it, the cloud provider’s responsibilities, and the procedures that apply when something changes or goes wrong.

Confirm the migration scope and risk classification

Security requirements depend on what is being moved and how important it is to the organisation. Create an inventory of the applications, databases, file stores, integrations and user groups included in the migration. For each item, record:

• What type of information it contains, such as personal, financial, commercially sensitive or operational data
• Which business processes depend on it
• Who is authorised to use or administer it
• What other systems it connects to
• What would happen if the information became unavailable, inaccurate or exposed

This assessment helps determine which workloads need stricter controls, additional approval or a different migration approach. It also prevents sensitive information being transferred simply because it happens to be stored alongside lower-risk data.

Check the cloud provider’s security responsibilities

Cloud security normally follows a shared-responsibility model. The provider may secure the underlying facilities, hardware and core service, while the customer remains responsible for areas such as account configuration, information, user permissions and supported applications. The exact division varies by service type and contract.

Before approval, document who is responsible for each control and how that responsibility will be evidenced. The review should consider the provider’s security documentation, independent assurance reports, data processing terms, breach notification arrangements, subcontractors, service locations and procedures for returning or deleting data when the contract ends. A provider’s general security credentials do not remove the need to configure and manage the customer’s own environment correctly.

Verify administrative separation

Administrative access deserves separate scrutiny because it can bypass ordinary business permissions. Confirm that administrative accounts are distinct from everyday user accounts and that privileged activity is limited to the people and tasks that require it. The design should also cover:

• Approval for creating, changing and removing privileged access
• Periodic reviews to identify unnecessary administrative permissions
• Separate roles for platform administration, application management and data ownership where appropriate
• Controls preventing one person from approving and carrying out a sensitive change without oversight
• Records showing which administrator performed an action and when

Emergency or break-glass access should have a documented purpose, secure storage, approval requirements and a review after use.

Confirm data governance and retention rules

Migration is an opportunity to remove obsolete information, duplicate records and data that no longer has a legitimate business purpose. Confirm what must be retained, for how long, and who can authorise disposal. Retention rules should apply to primary records, exported files, temporary migration copies and replicated data rather than just the main cloud repository.

Also establish how data will be labelled, searched and handled when shared. A simple classification scheme can identify information that may be broadly available internally and information that requires restricted handling. The scheme should be reflected in permissions, storage locations and sharing rules rather than existing only as a written policy.

Assess devices, connections and third-party access

A secure cloud service can still be exposed through an unmanaged laptop, an outdated mobile device or a supplier account. Confirm that devices accessing the new environment meet the organisation’s requirements for supported software, device security, patching and local data storage. Decide whether access is allowed from personally owned devices and, if so, what management and separation controls apply.

Review every external connection, including accounting systems, line-of-business applications, outsourced IT platforms, printers, scanners and supplier integrations. Each connection should have a documented owner, a defined purpose and only the access it needs. Unused interfaces and legacy accounts should be removed rather than carried into the new environment.

Review configuration standards before the move

Security settings should be based on an agreed baseline rather than left to default values. Confirm how the intended configuration will be created, checked and maintained across development, testing and production environments. Important questions include:

• Are publicly accessible services explicitly identified and approved?
• Are storage locations and shared workspaces restricted by default?
• Are administrative changes subject to review?
• Are unsupported protocols, unused services and unnecessary ports disabled?
• Will configuration drift be detected after the migration?

Capture the approved settings so that future changes can be compared against a known standard. A configuration that is secure on migration day can become unsafe if later alterations are not governed.

Confirm audit evidence and compliance records

Determine what evidence the organisation needs to demonstrate that controls are operating. This might include access reviews, change approvals, administrative activity, data exports, supplier assessments and records of security incidents. Confirm that the chosen cloud service can provide suitable logs or reports, that they are protected from unauthorised alteration, and that they are retained for the period required by the organisation’s policies or regulatory obligations.

Where personal data or sector-specific information is involved, document the lawful and contractual basis for processing, the relevant data locations and the process for responding to information requests. Security controls should support these obligations, but they do not replace formal legal or compliance advice where that is required.

Test the controls before production use

Do not rely solely on design documents or a supplier’s claims. Use a non-production environment or controlled pilot to test the permissions, data-handling rules, device requirements, administrative processes and recovery procedures. Record the test results, unresolved findings and the person responsible for each action.

Migration approval should be conditional on defined acceptance criteria. These may include confirmation that unauthorised users cannot access restricted information, approved users can complete essential tasks, former accounts no longer work, external connections behave as intended, and the organisation can produce the evidence required for review.

Set ownership for ongoing control management

Controls need an owner after the migration project ends. Assign responsibility for access reviews, supplier reviews, policy updates, configuration checks, staff guidance and investigation of exceptions. Include these activities in normal IT governance rather than treating security as a one-off migration task.

S2 Technology Group can help small and medium-sized organisations assess these requirements, document the control responsibilities and prepare a managed cloud environment around their operational needs. The key measure is not whether a service has been moved successfully, but whether its security can be demonstrated and maintained afterwards.