Daily cloud compromise assessments for UK telecoms.
Every day, Strand reviews your cloud tenants at forensic depth to determine if they've been compromised, and where the next threat may come from. If it finds something, Strand runs the full investigation: root cause, lateral movement, data exfiltration and reporting.
How often is your cloud estate actually examined? · Illustrative, rolling 12 months
Assessments recorded
1
Time between reviews
12 months
Latest evidence review
Sep 2025
Why telecoms
The accounts that control your network live in the cloud.
UK telecoms security rules changed. The Telecommunications Security Code of Practice, the government guidance that sits under the Telecommunications (Security) Act, was revised for 2026. It treats the systems that oversee your network as critical assets: authentication, monitoring, virtualisation and orchestration. Almost all of them are administered through cloud accounts.
Those accounts are what Strand examines: the administrators, service accounts, supplier applications and cross-cloud roles that can reach your network. It shows you whose access is too broad, what changed, and whether your logs show anyone misusing that access.
Plan on the basis that your critical systems may already be compromised without your knowledge.
Code of Practice 2026 · para 1.11
Hunt for threats in your logs on a regular cycle, in-house or through an independent third party.
Code of Practice 2026 · M16.02 and M16.03
Investigate incidents to root cause and act to stop them happening again.
Code of Practice 2026 · M5.05
Strand reads the logs behind those accounts every day, including activity that never raised an alert. In one published investigation, a digital forensics firm used Strand to find the root cause of an Akira ransomware attack and map the full attack chain in 30 minutes. Read the investigation.
The daily assessment
What could an attacker use? Has anyone already got in?
Every assessment answers both. The posture assessment finds the weaknesses: broad admin rights, missing MFA, risky application permissions, exposed storage. The compromise assessment goes through your logs for evidence that anyone has actually used them. Strand never reports a weakness as a breach.
1 · Posture assessment
No change since yesterday's assessment · 0 regressed · 0 resolved
Priority posture findings
Unused administrator roles still hold permanent access across two cloud accounts
Public object storage is accessible outside an approved exception
3 privileged accounts with no MFA registered
High-risk OAuth grant held by an unverified supplier application
Long-lived access key has no recorded rotation date
Posture by control domain
2 · Compromise assessment · past 30 days
Evidence sources
12
sign-in, audit, application, storage and admin logs
Review window
30 days
historical activity examined across connected clouds
Coverage gaps
3
each gap is listed in the result
Assessment cadence
Daily
timestamped posture and compromise record
The first assessment records a baseline of your estate and reviews your historical activity. Every assessment after that reports what changed and what happened since yesterday.
Fixing what it finds
Every finding names the fix.
Each finding identifies the setting, account or application affected, states the risk and gives the change that fixes it. Your team decides what to change and when.
- Enforce phishing-resistant MFA on the three privileged identities with no strong method recorded.
- Remove the supplier application's organisation-wide permissions and grant back only the ones it needs.
- Rotate the inactive AWS access key still attached to a privileged automation account.
- Require named reviewers and short expiry for application-consent requests.
- Remove broad cross-account role trust and limit the supplier role to the production resources it administers.
- Close anonymous sharing links and public object-storage access that have no approved business owner.
- Restrict temporary access and recovery methods to controlled onboarding workflows.
- Bring the Azure subscription with missing activity logs into the assessment scope.
- Limit guest invitations and external sharing to approved teams and domains.
- Remove unused service principals, workload identities and Google Workspace service accounts.
- Set maximum lifetimes for application secrets and rotate long-lived credentials.
- Document owners for privileged integrations and cross-cloud trust relationships.
The next assessment confirms whether the fix held. If a setting regresses weeks later, you hear about it the same day, not at the next annual review.
Daily assessment scope
The evidence Strand reviews across your cloud estate.
Strand covers Microsoft 365, Entra ID, Azure, AWS and Google Workspace. Every result states what was reviewed, the period it covers and anything that could not be collected.
Identity and authentication
Privileged roles, MFA, authentication policy, access keys and external identities across Microsoft Entra ID, AWS IAM and Google Workspace.
Applications and delegated access
Microsoft enterprise applications and OAuth grants, Azure service principals, AWS role trust and Google Workspace domain-wide delegation.
Mail, collaboration and storage
Forwarding, mailbox rules, guest access, anonymous links, public storage and external sharing across Microsoft 365, Azure Storage, Amazon S3 and Google Workspace.
Cloud infrastructure posture
Privileged configuration, logging, network exposure, encryption and access controls across Azure subscriptions and AWS accounts.
Activity and compromise signals
Microsoft audit events, Azure Activity Log, AWS CloudTrail and Google Workspace audit data reviewed for suspicious authentication, privilege change, persistence and data access.
Full incident investigation
If compromise is found, the same case continues across cloud, identity, endpoint and server evidence to establish cause, scope and impact.
From assessment to investigation
If something is found, Strand runs the full investigation.
Investigation is what Strand was built for. Digital forensics and incident response (DFIR) firms use it to run their investigations. When a daily assessment turns up real evidence, the same case continues: how the attacker got in, what they changed, where they moved, what data they reached and whether it left. Containment steps and the executive, technical and evidence reports come from the same platform. No waiting for an outside forensics team to start.
| Scope | M365 · Entra · Azure · AWS · Workspace |
| Reviewed period | 2026-07-23 to 2026-08-21 |
| Evidence reviewed | 12 cloud evidence sources |
| Items triaged | 6 |
| Result | No indicators identified in the reviewed sources |
| Limitations | 3 coverage gaps recorded |
| First evidence | 2026-08-02 · 03:41 UTC |
| Root cause | Unrotated secret in a supplier application |
| Persistence | New application credential identified |
| Lateral movement | 2 identities · 1 affected workload |
| Data access / exfiltration | SharePoint site and S3 bucket accessed · available logs show no bulk or external transfer |
| Response and reports | Sessions revoked · secrets rotated · application disabled · executive, technical and evidence reports |
Telecommunications Security Code of Practice 2026
The Code of Practice expects regular threat hunting. Strand does it daily and keeps the record.
The Code of Practice is the UK government's guidance on meeting the Telecommunications (Security) Act, and Ofcom assesses providers against it. The 2026 revision expects regular threat hunting in your logs and root-cause analysis after incidents. An independent third party can do the hunting. Strand performs that work across your connected cloud estate and records what was reviewed, what was found and what was fixed.
Public telecoms providers shall ensure that threat hunting is periodically performed using available logging and monitoring data.Telecommunications Security Code of Practice 2026, v1.1, M16.02
| Code expectation | How Strand supports the security team |
|---|---|
| Periodic threat hunting using available logging and monitoring data (M16.02) | A daily hunt through your cloud sign-in, application, storage and administrative logs for signs of attacker activity |
| Threat hunting may be performed by an independent third party (M16.03) | Strand acts as that independent hunting capability and keeps a dated record of each hunt: what was reviewed, what was found, any gaps and the follow-up |
| Identify incident root cause and take steps to prevent recurrence (M5.05) | A full investigation that documents cause, scope, impact and remediation |
| Prompt or real-time monitoring and retention of relevant source data (Regulation 6) | Strand works alongside your monitoring. It does not replace your monitoring or your log retention |
Alongside your SOC
Your SOC handles alerts. Strand examines the evidence.
Monitoring is built to spot known patterns and raise alerts. An attacker who signs in with valid stolen credentials and behaves like an administrator often triggers nothing. Strand does not wait for alerts. Every day it reads the logs themselves: sign-ins, permission changes, mailbox rules, application grants, storage access. Your SOC keeps its role. Strand hands it one conclusion a day with the evidence attached, not another queue of alerts.
| Endpoint protection (EDR / XDR) | Watches laptops and servers and blocks known-bad behaviour. |
| Security monitoring (SIEM / MDR / SOC) | Collects alerts, triages them and responds around the clock. |
| Strand daily assessment | Examines the cloud evidence itself, every day, and reports on posture and compromise. |
| Strand full investigation | Runs the investigation end to end: root cause, scope, impact, containment and the final report. |
28-day proof of concept
Run daily forensic assessments across your cloud estate for 28 days.
Connect Microsoft 365, Entra ID, Azure, AWS and Google Workspace. Assessments make no changes to your environment. For 28 days, Strand assesses each platform daily. You finish with a posture baseline, a prioritised fix list and a documented, dated answer to whether you have been compromised. If something is found, the same case carries straight into a full investigation.
Sources: Telecommunications Security Code of Practice 2026 (version 1.1), paragraphs 1.11 and 1.13, measures M5.05, M16.02 and M16.03 · Electronic Communications (Security Measures) Regulations 2022, Regulation 6 · Product scope and security controls: Strand Trust Center.