Cloud security reviews: follow an NCSC principle into the purchased service

For a cloud platform lead, “audit logging included” is an unfinished answer. It does not say which events are captured, how long they remain available or whether the security team can retrieve them when a customer reports a problem six weeks later. Those details can change both the architecture and the purchase price.

A cloud security review should make that journey from a broad assurance to a usable control. The NCSC principles provide a way to organise it, provided the review stays attached to the exact service being bought.

Start with the service boundary

If the requirement includes sovereignty, separate data location from legal authority and operational control. A regional hosting setting answers only part of that review.

The NCSC’s 14 cloud security principles apply to cloud platforms and Software as a Service. They describe security goals and ways a provider might meet them. The NCSC separates choosing a suitable provider from configuring the customer’s use securely. Treat the framework as a basis for examination, not a certificate awarded when every row contains a link.

Before requesting evidence, describe the proposed deployment in a paragraph: product and plan, region, sensitive data, identity connection, administrative access and important integrations. Include the business service that depends on it. A review of an isolated test tenant may be perfectly sound and still say little about the production service with external users and automated data exports.

Use that description to prioritise the questions. A system holding customer records needs a convincing account of access, separation and investigation. A platform supporting a critical transaction also needs a credible recovery arrangement. Every principle deserves consideration, but the unanswered questions with the greatest business consequences should drive the work.

Work one requirement all the way through

Take a hypothetical requirement: the security team must investigate administrative changes for 90 days. A provider document confirming that logs exist is a starting point. The review must establish that the required administrative events are present, that the purchased service retains or exports them, and that investigators can use them throughout the required period.

NCSC Principle 13, Audit information and alerting for customers, is particularly useful here. Its guidance addresses what information is supplied, when and in what format, retention, and relevant actions taken by provider personnel. That supports a much more precise evidence request than “please provide your security policy”.

Ask for a sample event from the proposed service and explain the investigation it must support. Can the analyst identify the actor, affected resource, action and outcome? Can they distinguish an administrator’s interactive change from an integration acting on the organisation’s behalf? Request a demonstration of the agreed event and retrieval path in a test configuration, with sensitive data removed.

The price implications become clear when the requirement meets a real product. Microsoft documents native retention for Entra ID audit and sign-in logs as seven days with Free and 30 days with P1 or P2. Longer retention needs an appropriate additional route, such as archiving through Azure Monitor. These logs are separate from the Microsoft 365 Unified Audit Log. Upgrading a licence does not recover activity that has already expired.

Against the hypothetical 90-day requirement, buying P1 or P2 alone therefore leaves work to do. The proposal needs to include the archive or analytics destination, its retention settings, access controls and running costs. It also needs a date on which collection will start. An export configured after a problem is reported cannot manufacture missing history.

Ask what makes the evidence applicable

Provider assurance, contractual availability and customer implementation answer different questions. An independent assurance report may increase confidence in the provider’s controls within its stated scope. The service documentation establishes which capabilities are offered. A configuration check and a representative test show whether the proposed deployment can use those capabilities.

Read the scope before relying on any report: the named service, period covered, exclusions and customer responsibilities. A strong report for one part of a supplier’s portfolio does not settle the review of another. Equally, a customer-side configuration gap need not mean that the provider’s underlying service is unsuitable. It may mean that the project has omitted an essential task or budget line.

Carry this distinction into the commercial conversation. If a required log is available only in another plan, procurement needs the revised price. If it is unavailable at any price, the architecture needs another source of evidence or a different service. If it exists but nobody can operate the export reliably, the service owner needs an operating commitment before go-live.

Make unresolved gaps change the decision

The useful output is a short set of decisions supported by evidence. For each material gap, explain the business requirement, what the proposed service actually supplies and the remaining work. Give a condition precise enough to close: “administrator events arrive in the investigation workspace and remain retrievable for 90 days” is stronger than “logging to be enabled”.

Some gaps can be closed before contract signature; others can become explicit conditions before production use. A gap that cannot be closed needs a conscious decision about a narrower use or an alternative service. Avoid allowing a conditional approval to become an unconditional launch simply because the implementation timetable has moved on.

Approve the configuration the team can afford and operate. For AI services, extend that same examination to the feature-specific data controls behind the provider’s assurance.