The First Five Logs Worth Turning On With No Security Team

Before you buy a single security tool, turn on logging for five things: identity and authentication events, admin actions, cloud API activity, endpoint activity, and network egress. Most of the breaches a small IT team actually has to deal with leave a trail in one of these five places, and most cloud platforms give you the raw logs for free. The gap usually isn't budget. Most of the time, nobody flipped the switch.

None of this requires a security operations center. It just means that if something goes wrong, you have evidence to work with instead of guesses.

Log 1: Identity and authentication events

Your identity provider (Microsoft Entra ID, Okta, Google Workspace) already logs every sign-in attempt. Most SMBs never turn on the audit or sign-in log export, or they turn it on and never look at it.

Decision rule: if you see a successful login from an unfamiliar country or an "impossible travel" pattern (same account, two locations, minutes apart) followed by a password reset or new device registration, treat it as a compromised account until proven otherwise. Lock it down first, investigate second.

This week: confirm sign-in logging is enabled and set a retention period long enough to look back at least a month. That's the minimum window most incidents take to surface.

Log 2: Admin actions

Authentication logs tell you who got in. Admin action logs tell you what they did with that access. Every major platform, your identity provider, your cloud console, your firewall, has an audit trail for privileged changes: new admin accounts created, MFA disabled, permissions escalated, firewall rules changed.

Decision rule: any MFA disablement, new admin or owner account, or permission escalation that happens outside a known change window is worth a five-minute check, every time. These are rare events in a healthy environment, which is exactly why they're cheap to monitor and expensive to ignore.

Log 3: Cloud API activity

If your infrastructure runs on AWS, GCP, or Azure, the platform is already recording every API call: who called it, from where, and what it changed. AWS CloudTrail, GCP Cloud Audit Logs, and Azure Activity Log are on by default in most accounts, but often not routed anywhere useful or retained long enough to matter.

This log category tends to reveal the most, and the fastest. In one engagement with a venture-backed technology company that had no dedicated security hire, a cloud security review across AWS and GCP surfaced more than 900 AWS findings and over 580 GCP findings once the logs and configurations were actually examined. Most of it was invisible until someone looked. Read more in the case study.

Decision rule: if you can't answer "who created or deleted this resource and when" within a few minutes, your cloud API logging isn't usable yet. Fix that before buying a cloud security tool on top of it. See our cloud security service for what a proper review looks like.

Log 4: Endpoint activity

You don't need a full EDR platform to start. Windows Defender, macOS's built-in logging, and most modern OSes already capture process execution, new persistence mechanisms, and security tool tampering. You just need it centralized somewhere, even a simple log collector, instead of trapped on each individual machine.

Decision rule: treat any of the following as an automatic escalation, not a "look at it later" item: antivirus or EDR disabled without a ticket, a new scheduled task or startup item you didn't create, or an Office document spawning a command shell. These three patterns show up in a disproportionate number of real intrusions.

Log 5: Network egress

Inbound traffic gets all the attention. Outbound traffic, what's leaving your network, is where data theft and command-and-control activity actually show up. Firewall logs, VPC flow logs, and DNS query logs will tell you this if they're turned on and someone's watching for the obvious patterns.

Decision rule: flag large or unusual outbound transfers to destinations you don't recognize, and DNS lookups to newly registered or oddly-named domains. You don't need to catch every anomaly. You need to catch the two or three patterns that account for most real exfiltration attempts.

"We don't have anyone to actually watch these logs"

This is the honest objection, and it's fair. Turning on five logs doesn't help if nobody ever reads them. There are three realistic paths:

• Set narrow, high-confidence alert rules (the ones described above) so you're only interrupted for things that genuinely matter, not every anomaly.

• Do a scheduled weekly review instead of real-time monitoring. Slower, but far better than nothing, and manageable for a lean IT team.

• Hand ongoing monitoring to a partner built for this. Our managed security service exists for exactly this gap, teams with real infrastructure and no bandwidth to watch it around the clock. If something does slip through, our incident response service picks up from there.

Whichever path you choose, the logs need to exist first. You can outsource watching them. You can't outsource having them.

Where to start this week

• Confirm sign-in and admin audit logs are enabled in your identity provider, with at least a month of retention.

• Turn on CloudTrail, Cloud Audit Logs, or Activity Log in every cloud account you run production in, and check they're not just enabled but actually routed and retained.

• Centralize endpoint logs from every machine, even into a basic collector, rather than leaving them local.

• Enable firewall and DNS logging for outbound traffic, and write down the two or three patterns you'd escalate on immediately.

None of this requires a big budget or a security hire. It requires someone to spend an afternoon flipping the right switches. If you want a second pair of eyes on what's already on, what's missing, and what's worth fixing first, start with a free security review: no pressure, just a clear picture of where you stand.