Serverless compliance

Serverless removes operating systems and patching from your audit. It leaves identity, code, dependencies, configuration and logging, and it multiplies the number of permissions to review.

Last reviewed 2026-09-30Written by Jacob Masse, TrazTech Inc.

A serverless architecture on AWS Lambda, Azure Functions or Google Cloud Run shrinks the audit: no servers to patch, harden or scan at the operating system level. What remains is function permissions, secrets, dependency vulnerabilities, event source exposure, logging and change management. Each function has its own identity, so least privilege becomes a larger review rather than a smaller one.

Controls that mostly go away

• Operating system patching and hardening.
• Host-based malware protection.
• SSH and RDP access management.
• Capacity planning for servers.

Your SOC 2 or ISO 27001 still lists these areas. The evidence becomes a statement that the provider handles them, backed by its report.

Controls that remain, or get harder

Function permissions

One role or identity per function, scoped to the resources it touches. Wildcard permissions copied between functions are the most common finding.

Secrets

From a secret manager at runtime, never in environment variables committed to code. See secrets management.

Dependencies

Serverless code is mostly third-party packages. Scan them in the repository and in the deployed artifact; Inspector covers Lambda on AWS.

Triggers and exposure

Function URLs, public HTTP triggers and API gateways need authentication decisions recorded. Unauthenticated endpoints should be intentional.

Logging

Function logs in CloudWatch, Azure Monitor or Cloud Logging, with retention set. Default retention on CloudWatch log groups is indefinite, which is a data retention question of its own.

Change management

Deploy through a pipeline, not the console editor.