Informes impresos con gráficas y tablas, sujetos con pinzas, sobre una mesa de madera

This is what you receive

A monthly report and an audit extract, with fictitious data, so you know what you will get before you sign up. The usual format for ENS (Spain's National Security Framework) documentation: cover page, version control, table of contents and page numbering.

Example with fictitious data. The company, figures and incidents on this page are made up to show the format. They do not correspond to any customer.

Monthly report

What a monthly report looks like

You receive it in the first week of every month. One page you can read in five minutes, with the detail underneath for anyone who wants it.

Example with fictitious data

Internal use

Monthly report

SRE service monthly report

September 2026

Prepared for: Example SaaS Ltd
Prepared by: SRE responsible for the service
Reference: EJ-SRE-INF-2026-09
Version: 1.0
Version date: 03/10/2026
Classification: Internal use

EJ-SRE-INF-2026-09Classification: Internal useExample with fictitious dataPage 1 of 8

SRE service monthly reportSeptember 2026

Version 1.0

03/10/2026

Page 2 of 8

Document control

Reference	EJ-SRE-INF-2026-09
Title	SRE service monthly report: September 2026
Version	1.0
Version date	03/10/2026
Status	Approved
Classification	Internal use
Created by	SRE responsible for the service
Reviewed by	Technical lead, Example SaaS Ltd
Approved by	CTO, Example SaaS Ltd
Purpose	To report on the state of the service in September 2026 (availability, incidents, changes, risks and vulnerabilities) and to record the actions agreed for the following month.

Version history

Version	Date	Author	Description of change
0.1	01/10/2026	SRE responsible for the service	Draft for review
1.0	03/10/2026	CTO, Example SaaS Ltd	Approved version

Distribution list

Recipient	Organisation
CTO	Example SaaS Ltd
Development team	Example SaaS Ltd
SRE responsible for the service	Service provider

EJ-SRE-INF-2026-09Classification: Internal useExample with fictitious data

SRE service monthly reportSeptember 2026

Version 1.0

03/10/2026

Page 3 of 8

1.Purpose and scopePage 4
2.Summary of the monthPage 4
3.Availability this monthPage 4
4.IncidentsPage 5
4.1502 errors on the API for 18 minutesPage 5
4.2Log disk at 85%Page 6
5.Changes madePage 6
6.Improvements madePage 6
7.Risks and recommendationsPage 7
8.VulnerabilitiesPage 7
8.1FixedPage 7
8.2Pending and whyPage 8

EJ-SRE-INF-2026-09Classification: Internal useExample with fictitious data

SRE service monthly reportSeptember 2026

Version 1.0

03/10/2026

Page 4 of 8

1. Purpose and scope

Client: Example SaaS Ltd
Period: September 2026
Service: SRE as a service, Standard plan
Platform: Managed Kubernetes on AWS, managed PostgreSQL, GitLab CI

2. Summary of the month

API availability: 99.95%, above the 99.9% target.
One incident with impact (18 minutes of API errors) and a minor one with no impact on users.
Cluster upgraded to a supported version and security patches applied to the nodes, with no downtime.
New risk: the certificate for the staging domain does not renew automatically. Proposal in the risks section.
Vulnerabilities: 23 found, 19 fixed and 4 pending, each with its justification.
Monthly PostgreSQL test restore completed in 24 minutes.

3. Availability this month

Service	Target	Actual	Downtime	Status
Public API	99.9%	99.95%	22 min	Met
Web dashboard	99.9%	99.97%	13 min	Met
Background jobs	99.5%	100%	0 min	Met
Staging environment	No target	98.8%	8 h 38 min	For information

Measured with external probes every minute. API downtime includes incident INC-0912 and 4 minutes of an announced maintenance window.

EJ-SRE-INF-2026-09Classification: Internal useExample with fictitious data

SRE service monthly reportSeptember 2026

Version 1.0

03/10/2026

Page 5 of 8

4. Incidents

4.1 502 errors on the API for 18 minutes

INC-0912High severity

Start: 12 September, 10:41
Detection: 10:43, automatic error rate alert
Service restored: 10:59
Impact: Around 30% of API requests returned an error for 18 minutes

Timeline

10:41A deployment mistakenly reduces the minimum number of API replicas from 3 to 1.
10:43The 5xx error alert fires. We start the diagnosis.
10:52The change in the Helm chart identified as the cause.
10:59Commit reverted; GitOps restores the 3 replicas and errors drop back to zero.

Cause: A chart default value changed between versions and the deployment did not pin it. The change review did not catch it because the diff did not show the inherited value.

Actions

Pin the minimum number of replicas in the production values (done, MR 418).
Add a pipeline check that fails if production drops below 2 replicas (task OPS-233, in progress).
Show the diff of the rendered chart values in every merge request (task OPS-234, pending).

EJ-SRE-INF-2026-09Classification: Internal useExample with fictitious data

SRE service monthly reportSeptember 2026

Version 1.0

03/10/2026

Page 6 of 8

4. Incidents (continued)

4.2 Log disk at 85%

INC-0926Low severity

Detection: 26 September, early warning alert
Impact: None for users

Cause: A new service was sending debug logs in production.

Actions

Log level fixed and Loki retention set to 30 days (done, MR 431).

5. Changes made

Date	Change	Reference	Downtime
3 Sep	Security patches for the cluster nodes	MR 402	No
10 Sep	Cluster upgraded to a supported version	MR 409	No
12 Sep	Minimum API replicas pinned in production	MR 418	No
18 Sep	Base image for the services updated	MR 423	No
24 Sep	PostgreSQL maintenance window (minor version)	MR 427	4 min, announced
26 Sep	Log retention set to 30 days	MR 431	No

6. Improvements made

Task	Description	Status
OPS-221	Shut down the staging environment outside business hours	Done
OPS-227	Certificate expiry alerts on all domains	Done
OPS-230	PostgreSQL test restore in an isolated account	Done
OPS-233	Minimum replica check in the pipeline	In progress
OPS-234	Diff of rendered values in merge requests	Pending

EJ-SRE-INF-2026-09Classification: Internal useExample with fictitious data

SRE service monthly reportSeptember 2026

Version 1.0

03/10/2026

Page 7 of 8

7. Risks and recommendations

Risk	Priority	Recommendation	Effort
The staging domain certificate is renewed by hand	Media	Move it to automatic renewal like the rest	S
Only one person on the team has admin access to the AWS account	Alta	A second administrator with two-factor authentication and documented break-glass access	S
A full production restore has not been rehearsed in another region	Media	Annual disaster recovery drill in another region	M

Estimated effort: S = hours, M = days, L = weeks.

8. Vulnerabilities

Found this month: 23
Fixed and verified: 19
Pending: 4, with justification
Critical and exposed to the internet: 0

8.1 Fixed

14 in container images: base image updated and services rebuilt (MR 423).
3 in API dependencies: patched versions after the tests passed (MR 425).
2 on the cluster nodes: operating system security patches (MR 402).

EJ-SRE-INF-2026-09Classification: Internal useExample with fictitious data

SRE service monthly reportSeptember 2026

Version 1.0

03/10/2026

Page 8 of 8

8. Vulnerabilities (continued)

8.2 Pending and why

Vulnerability	Where	Actual risk	Why it is still open	Plan
VUL-EJ-07 (CVSS 8.1)	Image library in the reporting service	Low: the affected function is not used and the service is not exposed	The vendor has not yet released a fixed version	Update as soon as it is out; checked every week
VUL-EJ-11 (CVSS 6.5)	PostgreSQL database	Low: only reachable from the private network	The fix requires a minor version upgrade with a restart	Window announced for 8 October
VUL-EJ-15 (CVSS 5.3)	Pipeline build tool	Very low: only in the build stage, with no production data	Waiting for the development team to validate the new version	Task OPS-238, this month
VUL-EJ-19 (CVSS 4.3)	Staging environment image	Very low: environment with no real data	Will be fixed with the October base image	Next monthly update

Continuous scanning of images, dependencies and systems with Trivy and Grype. Priority is set by actual risk (exposure, known exploitation and data affected), not just by the CVSS score. Fictitious identifiers. The full software inventory (SBOM) goes in an appendix.

EJ-SRE-INF-2026-09Classification: Internal useExample with fictitious data

Audit (extract)

What an audit looks like

An extract from the reliability and security audit report: the main risks, in order, with their evidence, and the prioritised improvement plan.

Example with fictitious data

Limited distribution

Audit (extract)

Reliability and security audit

Extract from the findings report

Prepared for: Example SaaS Ltd
Prepared by: SRE auditor
Reference: EJ-AUD-2026-01
Version: 1.0
Version date: 09/10/2026
Classification: Limited distribution

EJ-AUD-2026-01Classification: Limited distributionExample with fictitious dataPage 1 of 6

Reliability and security auditExtract from the findings report

Version 1.0

09/10/2026

Page 2 of 6

Document control

Reference	EJ-AUD-2026-01
Title	Reliability and security audit: Extract from the findings report
Version	1.0
Version date	09/10/2026
Status	Approved
Classification	Limited distribution
Created by	SRE auditor
Reviewed by	Technical lead, Example SaaS Ltd
Approved by	Managing director, Example SaaS Ltd
Purpose	To identify the reliability and security risks of the platform, rank them by impact and propose a prioritised improvement plan with the estimated effort for each action.

Version history

Version	Date	Author	Description of change
0.1	06/10/2026	SRE auditor	Draft with the review findings
0.2	08/10/2026	Technical lead, Example SaaS Ltd	Team comments incorporated
1.0	09/10/2026	Managing director, Example SaaS Ltd	Approved version

Distribution list

Recipient	Organisation
Managing director	Example SaaS Ltd
Technical lead	Example SaaS Ltd
SRE auditor	Service provider

EJ-AUD-2026-01Classification: Limited distributionExample with fictitious data

Reliability and security auditExtract from the findings report

Version 1.0

09/10/2026

Page 3 of 6

1.Purpose and scopePage 4
2.The 3 main risksPage 4
2.1The database backups have never been restoredPage 4
2.2Only one person, who has since left, knew how deployment workedPage 5
2.3Outages are detected by clientsPage 5
3.Other points to review laterPage 6
4.Prioritised improvement planPage 6

EJ-AUD-2026-01Classification: Limited distributionExample with fictitious data

Reliability and security auditExtract from the findings report

Version 1.0

09/10/2026

Page 4 of 6

1. Purpose and scope

Company: Example SaaS Ltd
Date: 6 October 2026
Source: Review with read access to the cloud account, the servers and the repository, plus an interview with the team
Platform reviewed: Two servers at Hetzner with Docker Compose, self-hosted PostgreSQL, GitLab.com

A team of five developers, with no one in operations since the person who set up the servers left. Around 40 paying clients use the application during business hours. A new client has sent a security questionnaire.

2. The 3 main risks

Estimated effort: S = hours, M = days, L = weeks.

2.1 The database backups have never been restored

High priorityEffort S

Evidence: There is a daily PostgreSQL dump on the same server and a weekly disk snapshot from the provider. Nobody has restored either of them.
Why it matters: If the server is lost, the daily backup is lost with it, and there is no way of knowing how long it would take you to recover or whether the weekly backup boots.
Recommendation: A daily backup off the server and in another location, one of them immutable, and a test restore on an isolated machine with the time recorded.

EJ-AUD-2026-01Classification: Limited distributionExample with fictitious data

Reliability and security auditExtract from the findings report

Version 1.0

09/10/2026

Page 5 of 6

2. The 3 main risks (continued)

2.2 Only one person, who has since left, knew how deployment worked

High priorityEffort M

Evidence: Deployment is done over SSH with a script on the server. The SSH keys of the person who left are still active and there is a shared admin password.
Why it matters: Access that has not been revoked is an open door, and a deployment nobody understands turns every change into a risk.
Recommendation: Revoke the old keys and passwords, named accounts with two-factor authentication and a GitLab CI pipeline that deploys with review and rollback.

2.3 Outages are detected by clients

Medium priorityEffort S

Evidence: There is no external monitoring and no alerting. Last quarter there were two outages that clients reported by email.
Why it matters: Every outage a client discovers lasts longer and costs trust, just when a new client is asking you for guarantees.
Recommendation: External availability probes, basic metrics with Prometheus and alerts for disk, certificates and errors, with a clear notification channel.

EJ-AUD-2026-01Classification: Limited distributionExample with fictitious data

Reliability and security auditExtract from the findings report

Version 1.0

09/10/2026

Page 6 of 6

3. Other points to review later

PostgreSQL version close to end of support.
Admin ports open to the internet on one of the servers.
No documentation on how to rebuild the servers from scratch.

4. Prioritised improvement plan

First, backups off the server with a tested restore (days), then access and the deployment pipeline (1-2 weeks) and, in parallel, monitoring. You can do it with your own team or with us, as a project or as part of SRE as a service.

EJ-AUD-2026-01Classification: Limited distributionExample with fictitious data

See the reliability and security audit

Tell us about your case

In a free 20-minute call we look at where you are and where to start. No commitment.

Book a 20-minute call

This is what you receive

What a monthly report looks like

Document control

Version history

Distribution list

Contents

1. Purpose and scope

2. Summary of the month

3. Availability this month

4. Incidents

4.1 502 errors on the API for 18 minutes

4.2 Log disk at 85%

5. Changes made

6. Improvements made

7. Risks and recommendations

8. Vulnerabilities

8.1 Fixed

8.2 Pending and why

What an audit looks like

Document control

Version history

Distribution list

Contents

1. Purpose and scope

2. The 3 main risks

2.1 The database backups have never been restored

2.2 Only one person, who has since left, knew how deployment worked

2.3 Outages are detected by clients

3. Other points to review later

4. Prioritised improvement plan

Tell us about your case