An employee signs in to Microsoft 365 from a new location, and shortly afterwards a mail rule starts forwarding invoice messages to an external address. That need not mean an incident, but it does need checking. Which is why the question of how to monitor a cloud environment is not only about whether servers and applications are running. It is mainly about who is reaching the data, what they are doing, and whether the configuration still protects the company the way it should.<\/p>\n
The cloud simplifies work, but it changes how risk is managed. Part of the infrastructure is maintained by the provider, while responsibility for user accounts, permissions, data, configuration and the response to suspicious events stays with the organisation. Effective monitoring should therefore help distinguish ordinary activity from the signal of an account takeover, an administrator’s mistake or an attempt to steal data.<\/p>\n
In many SMEs “the cloud” means mainly email and files in Microsoft 365 or Google Workspace. In practice the environment is usually wider: administrative accounts, user devices, SaaS applications, virtual machines, backups, firewalls, VPN connections and local systems exchanging data with the cloud.<\/p>\n
You cannot sensibly monitor everything equally. The first step is an inventory of assets and a decision about how much each matters to the business. A shared sales mailbox is not the same as a global administrator account, and different again from a system holding client documentation or accounting records.<\/p>\n
Three simple questions help: where is the data that matters to the company, who can read or change it, and which events could stop work? That map lets you set priorities without deploying excessively elaborate tooling.<\/p>\n
Availability monitoring answers whether a service is running. Security monitoring answers whether someone is using it without authorisation. Both are needed, but they should not be treated as the same thing.<\/p>\n
A compromised cloud account is one of the more common ways into an organisation. An attacker does not always have to crack a password – they may use a phishing message, extract an MFA code or hijack an active session.<\/p>\n
So it is worth recording and analysing failed sign-in attempts, access from unusual locations or devices, sudden changes to authentication methods and the use of privileged accounts. Administrator accounts need particular attention, because taking one over can allow security policies to be changed, new users created or many people’s data reached.<\/p>\n
Reviewing permissions periodically matters just as much. Someone who has changed role or left the company should not keep access simply because the account still exists. Least privilege limits the consequences of both a mistake and a single compromised identity.<\/p>\n
Email remains the main channel for phishing and business fraud. In Microsoft 365 and Google Workspace environments it is worth monitoring the creation of automatic forwarding rules, changes to mailbox settings, unusual sending patterns and sign-ins to shared accounts.<\/p>\n
For files, what matters is mass downloading, deletion or external sharing. A single download may be ordinary work, but a large number of operations in a short time – especially from an account on an unfamiliar device – should be verified.<\/p>\n
Context is decisive. An alert about a sign-in from abroad does not always mean an attack, because the employee may be travelling. The same alert can be urgent if it follows a series of failed logins, a password change and an attempt to create a forwarding rule. Effective alert analysis joins such signals rather than judging each in isolation.<\/p>\n
Cloud misconfigurations are often invisible to users yet can open the way to unauthorised access. Examples include overly broad permissions, multi-factor authentication switched off, publicly accessible data stores, uncontrolled access keys and stale service accounts.<\/p>\n
Monitoring should detect significant changes to configuration and policy. That applies to servers and virtual machines running in the cloud too: new administrative connections, changes to network rules, unexpected processes or attempts to disable protective mechanisms. Data from EDR<\/a> – tooling that monitors activity on devices and servers – can complement cloud service logs here.<\/p>\n Logs are the record of events: sign-ins, permission changes, file operations, administrative activity and communication between systems. Without them it is hard to reconstruct an incident, and harder still to notice one early.<\/p>\n Collecting a large volume of logs does not provide protection on its own. A company needs answers on which sources are critical, how long the data must remain available and who will act on what is found. In a small environment it is more sensible to start with identity accounts, email, endpoints, the firewall and the most important systems than to try covering every part of the infrastructure at once.<\/p>\n Central collection and correlation in a SIEM makes it easier to join information from different sources – linking, for example, an unusual Microsoft 365 sign-in with an EDR alert on the user’s computer. It does not replace the person who judges whether the situation is a threat or has a legitimate business explanation; our article on SOC versus SIEM<\/a> covers that difference.<\/p>\n Monitoring delivers most when a concrete action follows an alert. The organisation should decide in advance who can block an account, how to contact a user other than through a potentially compromised mailbox, and when a device should be isolated from the network.<\/p>\n The procedure need not be long, but it should cover the most common scenarios: a suspicious sign-in, phishing, an account takeover, suspected ransomware and unauthorised data sharing. In each case name the person responsible, the escalation route and the actions that limit the impact.<\/p>\n Bear in mind that automatically blocking every unusual sign-in can disrupt salespeople, engineers or anyone travelling. On the other hand, rules that are too permissive give an attacker more time. Settings should follow how the company actually works, and then be reviewed regularly.<\/p>\n Attacks and irregular activity do not appear only during office hours. A mailbox taken over on a Friday evening can be used to defraud business partners before Monday morning. During that time the number of events can grow while the chance of limiting the damage falls.<\/p>\n An in-house team capable of watching the environment around the clock, analysing alerts and responding to incidents is disproportionately expensive for many SMEs. SOC as a Service<\/a> and MDR make 24\/7 monitoring and analyst expertise available without building a full internal team. The scope should match the infrastructure, the critical processes and the organisation’s maturity, rather than a list of technologies.<\/p>\n For companies preparing for expectations under NIS2<\/a>, ISO 27001 or GDPR<\/a>, monitoring can also supply material for risk assessment and help put processes in order. It is not in itself confirmation of compliance. Requirements always have to be read against the specific organisation, its data, processes and obligations.<\/p>\n A short review of the environment is a good starting point: which cloud services are in use, which accounts are privileged, how authentication works, what log sources exist and what response procedures are in place. Then enable multi-factor authentication wherever it is available, remove excessive permissions and bring the highest-risk events into monitoring.<\/p>\n The next step is testing the process. If a system detects a suspicious sign-in, the company should know not only that an alert was raised, but who receives it, how quickly they assess it and what they do once the threat is confirmed. Only then does technology translate into a real reduction in the risk of downtime and data loss.<\/p>\n A cloud environment changes as the company does: users, applications, integrations and new ways of working keep arriving. Monitoring is not a one-off deployment but a continuous process, worth adapting to those changes before they become the source of a problem. If you would like a review of what your cloud environment currently shows you, get in touch with our team<\/a>.<\/p>\n Chief Technology Officer (CTO). For security reasons we do not publish authors’ names – articles are signed by role only, without details identifying a specific person.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" How to monitor a cloud environment, detect threats and reduce the risk of downtime, data leaks and account takeover in a company using public cloud.<\/p>\n","protected":false},"author":78325378,"featured_media":4377,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_kad_blocks_custom_css":"","_kad_blocks_head_custom_js":"","_kad_blocks_body_custom_js":"","_kad_blocks_footer_custom_js":"","_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[30],"tags":[],"class_list":["post-4462","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cybersecurity"],"taxonomy_info":{"category":[{"value":30,"label":"Cybersecurity"}]},"featured_image_src_large":["https:\/\/www.virtuosoc.com\/wp-content\/uploads\/2026\/09\/jak-monitorowac-srodowisko-chmurowe-w-firmie-featured-1024x683.webp",1024,683,true],"author_info":{"display_name":"claude_ax285500","author_link":"https:\/\/www.virtuosoc.com\/en\/author\/claude_ax285500\/"},"comment_info":0,"category_info":[{"term_id":30,"name":"Cybersecurity","slug":"cybersecurity","term_group":0,"term_taxonomy_id":30,"taxonomy":"category","description":"","parent":0,"count":22,"filter":"raw","cat_ID":30,"category_count":22,"category_description":"","cat_name":"Cybersecurity","category_nicename":"cybersecurity","category_parent":0}],"tag_info":false,"_links":{"self":[{"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/posts\/4462","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/users\/78325378"}],"replies":[{"embeddable":true,"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/comments?post=4462"}],"version-history":[{"count":0,"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/posts\/4462\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/media\/4377"}],"wp:attachment":[{"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/media?parent=4462"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/categories?post=4462"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.virtuosoc.com\/en\/wp-json\/wp\/v2\/tags?post=4462"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Collect logs, but decide what they are for<\/h2>\n
Agree the response rules before an incident<\/h2>\n
Why 24\/7 monitoring matters for an SME<\/h2>\n
Where to start in practice<\/h2>\n