A two-person IT team does not need a SIEM to collect defensible incident evidence; it needs a short list of retained log sources, a repeatable way to preserve relevant records, and an evidence register showing who collected what and when. The incident evidence requirements for small IT team without siem can be met by combining your identity provider, cloud platform, endpoint tooling, ticketing system, and immutable storage with a documented incident procedure. For ISO 27001:2022 control 5.28, the auditor is looking for evidence that you can identify, collect, acquire, and preserve records related to information security events—not proof that you purchased enterprise monitoring software.
What are the incident evidence requirements for small IT team without siem?
The 80/20 version of ISO 27001 control 5.28 is simple: when a suspected security event occurs, your team must be able to preserve the facts before they are overwritten, altered, or lost. For a SaaS company completing an enterprise questionnaire while preparing for a surveillance audit, this means demonstrating a practical process rather than building a security operations center.
Your minimum evidence set should answer five questions:
- What happened? Preserve the alert, report, ticket, user complaint, or automated detection that started the investigation.
- When did it happen? Capture timestamps, ensure systems use synchronized time, and note the relevant time zone.
- Which accounts, devices, systems, or data were involved? Retain identity, endpoint, cloud, application, and access records that establish scope.
- What did the team do? Keep a chronological incident record of containment, remediation, communications, and decisions.
- How was the evidence protected? Store copies in a restricted location, record access, and avoid editing original exports.
Do not confuse “collect every log forever” with evidence collection. A two-person team should retain the records most likely to establish account access, administrative changes, production activity, source-code access, and endpoint actions. Your incident response procedure should define the sources, the person responsible for collection, the storage location, and the approval path for deleting evidence.
Which free or low-cost tools can replace a SIEM for incident evidence?
Use the tools already embedded in your SaaS operating model. The goal is not one central dashboard; it is reliable exports and retained records from the systems that matter most. For a typical startup with Google Workspace or Microsoft 365, AWS, GitHub, and managed endpoints, the following stack is usually sufficient.
| Evidence need | Practical tool | Recommended setting | What to preserve during an incident |
|---|---|---|---|
| Identity and admin activity | Google Workspace Admin console or Microsoft Purview | Enable audit logging; export monthly admin, login, Drive, and OAuth activity | Login history, MFA changes, mailbox rules, OAuth grants, admin actions |
| Cloud control-plane records | AWS CloudTrail and CloudWatch Logs | Multi-region trail; log file validation; deliver to a dedicated S3 bucket | CloudTrail JSON files, IAM changes, security group changes, console logins |
| Source-code and CI/CD activity | GitHub Enterprise Cloud or GitHub Organization audit log | Retain audit-log exports monthly; require SSO and branch protection | Audit log CSV/JSON export, pull requests, deployment workflow runs, token changes |
| Endpoint investigation | Microsoft Defender for Business, Huntress, or osquery | Enable device inventory, malware alerts, and 90-day telemetry where available | Device timeline, alert details, running-process data, isolation actions |
| Case management | Jira, Linear, or a restricted GitHub repository | Create one incident template with limited access for founders and IT | Timeline, decisions, screenshots, exports, owner, closure approval |
| Preserved evidence storage | Amazon S3 with Object Lock or Google Drive with restricted access | Separate evidence folder or bucket; deny routine deletion; retain for 12 months minimum | Original exports, hashes, screenshots, communications, forensic reports |
For AWS, a dedicated evidence bucket is an especially strong low-cost shortcut. Configure CloudTrail to write to it or to a separate logging bucket, restrict write and delete permissions, and enable S3 Versioning. If your subscription and retention needs justify it, use S3 Object Lock in governance mode. This gives you a credible preservation story without operating a SIEM.
Incident evidence folder naming convention:
INC-2026-014-suspicious-oauth-grant/
00-case-summary.md
01-original-alert/
02-identity-logs/
03-cloud-logs/
04-endpoint-records/
05-containment-actions/
06-communications/
evidence-register.csv
Example evidence-register.csv entry:
INC-2026-014,EV-003,Google Workspace login audit CSV,
2026-07-16T14:22:09Z,Collected by J. Chen,
SHA-256: 8f0d...c39a,Restricted S3 evidence bucket,
Google Admin export; original file not modifiedWhat manual processes will still work when your company reaches 50 employees?
A lightweight process works until about 50 employees if it assigns ownership clearly and removes judgment calls during a stressful event. The founder does not need to perform technical collection, but should approve material customer notifications, legal escalation, and incident closure when the event affects customer data or service availability.
Create an incident evidence procedure with these operating rules:
- Open a case immediately. Use a sequential identifier such as
INC-2026-014. Record the reporter, detection time, affected service, incident lead, and initial severity. - Preserve before remediating where feasible. Export logs, take screenshots, capture relevant configuration, and record the state of affected accounts before disabling, deleting, rotating, or rebuilding them.
- Keep originals separate from working notes. Upload raw exports into an “original evidence” folder. Analysts may create copies for filtering or annotation, but should not overwrite originals.
- Maintain a simple chain of custody. Your register needs the evidence ID, description, source, collector, collection time, storage location, and hash for important files.
- Document every meaningful action. Record who disabled an account, revoked a token, changed a firewall rule, restored a backup, or notified a customer—and when.
- Review closure. A second person, such as the founder, engineering lead, or outsourced security adviser, confirms that evidence is stored, lessons are assigned, and retention dates are set.
For the incident-evidence needs of a small IT team without a SIEM, a monthly 20-minute review is more valuable than a complex platform nobody maintains. Verify that CloudTrail is still writing, identity audit logs are available, endpoint coverage has not lapsed, the evidence storage location is restricted, and the incident template still reflects your current systems.
How long should a small SaaS company retain incident evidence?
Set a documented baseline of 12 months after incident closure, unless a customer contract, legal hold, insurance requirement, or regulatory obligation requires longer retention. Keep the policy realistic: a small team is more likely to follow a one-year baseline consistently than an ambitious multi-year promise with no storage budget or owner. If an event may lead to litigation, a customer dispute, or regulatory inquiry, suspend normal deletion and preserve records until counsel or management authorizes release.
When should a small team hire or outsource incident evidence collection?
Outsource when the incident exceeds your ability to preserve reliable facts while keeping the business running. That threshold is often lower than founders expect. Call your managed detection and response provider, incident response retainer, cyber insurer breach coach, or specialist counsel when there is suspected customer-data exposure, ransomware, privileged-account compromise, a production intrusion, employee misconduct requiring forensics, or a likely notification obligation.
You should also obtain outside help if you cannot answer whether logs are complete, whether an endpoint image is needed, or whether remediation will destroy evidence. An external responder can collect forensic images, preserve volatile cloud and endpoint artifacts, determine scope, and provide an independent report. Your internal team still owns the first hour: open the case, preserve available logs, restrict access to evidence, and avoid wiping or reimaging affected systems until advised.
How can you prove ISO 27001 compliance without enterprise tools?
For an ISO 27001 surveillance audit, show a coherent package rather than a product screenshot. Map your package to control 5.28’s requirement to identify, collect, acquire, and preserve evidence related to information security events.
- Your approved incident response and evidence-collection procedure, including roles and escalation criteria.
- An evidence-source inventory listing Google Workspace or Microsoft 365, AWS, GitHub, endpoint tooling, application logs, retention periods, and owners.
- Configuration evidence such as CloudTrail settings, S3 bucket access controls, identity audit-log settings, and endpoint-management coverage.
- One sanitized incident record or tabletop exercise showing the alert, timeline, evidence register, stored exports, containment actions, and closure review.
- Monthly or quarterly review records showing that logging and evidence storage remain operational.
When an enterprise customer asks whether you use a SIEM, answer accurately: you may not operate a SIEM, but you maintain centralized audit sources for critical systems and a documented process to collect and preserve incident evidence. That response is stronger than claiming a capability you cannot operate, and it directly addresses the incident evidence requirements for a small IT team without a SIEM.
Next step: before your surveillance audit, run one 30-minute tabletop exercise using your incident template and save the resulting evidence register as your proof that the process works.
