← Back to Blog
Monitoring2026-04-04· 5 min read

Building a Security Monitoring Program on a Startup Budget

Building a Security Monitoring Program on a Startup Budget

Photo by Vitaly Gariev on Unsplash

The Budget Reality

Enterprise SIEM solutions cost $100,000 to $500,000 per year. Managed detection and response services run $5,000 to $25,000 per month. For a startup burning through its Series A, these numbers are non-starters.

But having zero monitoring isn't acceptable either. Without visibility into your environment, you won't know when credentials are compromised, when data is being exfiltrated, or when someone is probing your infrastructure. Most breaches at small companies go undetected for months because nobody was watching.

The good news: you can build a meaningful monitoring program for a fraction of enterprise costs using cloud-native services, open-source tools, and smart prioritization of what to watch.

Step 1: Define What Matters

You can't monitor everything, so monitor the things that would hurt most if compromised.

For most startups, the critical assets are:

  • Cloud infrastructure accounts — AWS root, GCP org admin, Azure global admin
  • Source code repositories — GitHub/GitLab organization settings and access
  • Production databases — Customer data, financial records
  • Identity provider — Google Workspace, Okta, or whatever manages authentication
  • Payment processing — Stripe, Braintree, or direct payment infrastructure

Start with these five. Everything else can wait.

Step 2: Enable Cloud-Native Logging (Free or Cheap)

Every major cloud provider includes basic logging capabilities. You just need to turn them on.

AWS

  • CloudTrail — Logs every API call in your account. Free for management events, charged for data events. Enable it. This is your single most important data source.
  • GuardDuty — Threat detection service that analyzes CloudTrail, VPC flow logs, and DNS logs. Roughly $1-2 per million events. For a small environment, this might cost $30-50/month and provides genuinely useful detection.
  • Config — Tracks resource configuration changes. Useful for detecting drift.

GCP

  • Cloud Audit Logs — Enabled by default for admin activity. Enable data access logs for critical services.
  • Security Command Center — Free tier includes security health analytics and basic threat detection.

Azure

  • Activity Log — Enabled by default, tracks control plane operations.
  • Microsoft Defender for Cloud — Free tier provides security posture assessment. Paid plans add threat detection.

Google Workspace / Microsoft 365

  • Audit logs — Both platforms provide admin and user activity logs. Export them or at minimum, review them weekly.
  • Alert policies — Configure built-in alerts for suspicious login activity, admin changes, and data sharing anomalies.

Total cost for cloud-native logging: typically under $100/month for a small environment.

Step 3: Centralize Your Logs

Having logs scattered across five different dashboards means nobody looks at any of them. Centralize into one place.

Budget Option: ELK Stack on a Single Instance

Elasticsearch, Logstash, and Kibana running on a single VM can handle a small organization's log volume. Deploy it in your cloud account, ship logs via Filebeat and CloudWatch/Pub-Sub integrations. Total cost: the price of one VM, maybe $50-100/month.

The downside: you're maintaining infrastructure. Elasticsearch needs disk management, index rotation, and occasional care.

Better Option: Cloud-Native Log Aggregation

  • AWS CloudWatch Logs — Already captures most AWS service logs. Add Insights for querying.
  • GCP Cloud Logging — Centralized by default. Use Log Analytics for SQL-based queries.
  • Grafana Cloud Free Tier — 50GB of logs per month, which is sufficient for a small startup. Includes alerting.

Practical Option: Wazuh

Wazuh is open-source and combines log analysis, intrusion detection, file integrity monitoring, and vulnerability detection. It's more than a log aggregator and the learning curve is moderate. Deploy the Wazuh server in your cloud environment and install agents on your endpoints. Total cost: infrastructure only.

Step 4: Build Five Essential Alerts

Don't try to build 200 alert rules. Start with five that detect the highest-risk scenarios:

Alert 1: Root/Admin Account Login

Any login to a cloud root account, domain admin, or organization owner should fire an immediate alert. These accounts should rarely be used directly. If someone logs in, you want to know.

Implementation: CloudTrail event filter for ConsoleLogin by root user. Google Workspace alert for super admin login.

Alert 2: New Admin User Created

When a new administrator account appears, it could be legitimate onboarding or it could be persistence after a compromise. Either way, you want to verify.

Implementation: CloudTrail filter for CreateUser or AttachUserPolicy with admin permissions. Google Workspace alert for admin role assignment.

Alert 3: Security Group or Firewall Change

Opening a port to the internet — especially SSH (22), RDP (3389), or database ports — is either a deliberate change or a dangerous mistake. Both warrant review.

Implementation: CloudTrail filter for AuthorizeSecurityGroupIngress with 0.0.0.0/0. GCP filter for firewall rule changes.

Alert 4: Impossible Travel

A user logs in from New York and 30 minutes later from Singapore. Either they're on a very fast plane or their credentials are compromised.

Implementation: Google Workspace and Microsoft 365 have built-in impossible travel detection. For custom implementations, compare login geolocations within time windows.

Alert 5: Data Export or Bulk Access

A user downloads the entire customer database, exports all contacts, or accesses an unusual volume of records. This could be a departing employee or a compromised account.

Implementation: Application-level logging for bulk operations. Database query auditing for large SELECT statements. SaaS platform alerts for mass downloads.

Step 5: Establish a Review Cadence

Alerts are for real-time response. But you also need periodic review of things that don't trigger alerts.

Daily (5 minutes): Scan your alert dashboard. Were there any alerts? Were they handled? Any patterns?

Weekly (30 minutes): Review access logs for your identity provider. Any new accounts? Any unusual login patterns? Any failed MFA attempts? Check your cloud posture tool for new findings.

Monthly (2 hours): Review user access lists for critical systems. Are there accounts that should have been deactivated? Review your alert rules — are they too noisy? Too quiet? Update based on what you've learned.

What This Costs

A realistic budget for a startup security monitoring program:

| Component | Monthly Cost | |-----------|-------------| | Cloud-native logging (CloudTrail, GuardDuty) | $50-100 | | Log centralization (Grafana Cloud free or small VM) | $0-100 | | Wazuh server (if using) | $50-150 (VM cost) | | Analyst time (your time, 2-3 hrs/week) | $0 (existing headcount) | | Total | $100-350/month |

Compare that to a commercial SIEM at $8,000/month. You're trading money for time and polish, but the core detection capabilities are there.

When to Graduate to Commercial Tools

This approach works until it doesn't. You'll know it's time to upgrade when:

  • Your log volume exceeds what your centralization tool handles affordably
  • You need compliance reports that require specific log retention and audit trails
  • Alert tuning consumes more than a few hours per week
  • You hire a dedicated security analyst who needs professional tooling

Until then, cloud-native services, open-source tools, and five well-tuned alerts will catch more real threats than an expensive SIEM that nobody has time to manage.