SOC 2 Compliance for Laravel Applications: A Technical Implementation Guide

SOC 2 is the compliance standard that enterprise buyers ask for first. If you sell B2B software, especially to healthcare, finance, or any company with a vendor security programme, you will eventually face the question: "Can you send us your SOC 2 report?"

This guide is for Laravel developers and engineering leads who need to understand what SOC 2 actually requires technically, not just in policy terms. We will map the Trust Service Criteria to specific Laravel configurations, show you what evidence auditors collect, and explain how to avoid the mistakes that derail most first-time audits.

What SOC 2 Is

SOC 2 (Service Organization Control 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA). It defines criteria for managing customer data based on five Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Unlike ISO 27001, which specifies a management system, SOC 2 evaluates whether your controls are operating effectively against the criteria. There is no single correct implementation — you define your controls, and the auditor evaluates whether they work as described and whether they meet the TSC requirements.

Type I vs Type II

SOC 2 Type I is a point-in-time assessment. The auditor reviews your control descriptions and configurations as of a specific date and opines that the controls are suitably designed. It does not test whether they actually worked over time.

SOC 2 Type II covers an observation period, typically six to twelve months. The auditor tests samples of evidence from throughout the period and attests that controls were operating effectively. This is what serious enterprise buyers require.

Type I is useful as a first step if you need a report quickly, but it is not a substitute for Type II. Plan to pursue Type II from the start, and use the observation period to prove your controls are not just designed but embedded into your engineering operations.

Trust Service Criteria structure

Each TSC contains numbered criteria, for example CC6.1 or CC7.2. The CC prefix stands for Common Criteria, which apply to the Security TSC and are required for every SOC 2 report. Additional criteria apply if you opt into Availability (A1), Processing Integrity (PI1), Confidentiality (C1), or Privacy (P1–P8).

Which TSC Matter for a Laravel SaaS

For most Laravel SaaS businesses, the relevant categories are:

Security (Common Criteria) — mandatory. These cover logical access, change management, risk management, and monitoring. They are always included.

Availability. If your SaaS has uptime SLAs or if downtime directly harms customers — for example a payment processing or healthcare application — Availability criteria (A1.1–A1.3) will be expected.

Confidentiality. If you process confidential customer data under NDA or have contractual data handling commitments, C1.1 and C1.2 apply. Most B2B applications should include this.

Privacy (P1–P8). Required if you collect, use, retain, disclose, or dispose of personal information and have made privacy commitments (for example via a privacy notice).

For a typical B2B Laravel SaaS, start with Security and Confidentiality, add Availability if you have SLAs, and defer Privacy unless customers explicitly require it.

Technical Controls for Laravel

The criteria that trip up most Laravel teams are in the Common Criteria around logical access (CC6.x) and anomaly detection (CC7.x). Here is what each requires and how to implement it.

Access Controls (CC6.1, CC6.2, CC6.3)

CC6.1 requires that access to systems is limited to authorised users and that access is granted based on job responsibility (least privilege).

Implement role-based access in Laravel:

// app/Enums/Role.php
enum Role: string
{
    case Admin  = 'admin';
    case Editor = 'editor';
    case Viewer = 'viewer';
}

// In a gate or policy
Gate::define('manage-users', function (User $user) {
    return $user->role === Role::Admin;
});

Use Laravel's built-in Gate and Policy classes rather than ad-hoc if ($user->is_admin) checks scattered across controllers. Auditors want to see a centralised, documented access control mechanism they can test.

Enforce multi-factor authentication:

MFA on administrative interfaces is one of the most frequently tested controls. Use a package like laravel-fortify with TOTP support, or integrate with an identity provider (Okta, Auth0) that enforces MFA at the IdP level.

// config/fortify.php
'features' => [
    Features::registration(),
    Features::resetPasswords(),
    Features::twoFactorAuthentication([
        'confirm' => true,
        'confirmPassword' => true,
    ]),
],

For your admin panel specifically (Laravel Nova, Filament, or a custom admin route group), enforce MFA as a middleware requirement — never leave it optional for privileged users.

Session management:

// config/session.php
'lifetime'        => 120,   // 2 hours — adjust to your security policy
'expire_on_close' => true,
'secure'          => true,  // HTTPS only
'http_only'       => true,
'same_site'       => 'strict',

CC6.2 requires that user access is reviewed periodically and revoked when no longer needed. Document a quarterly access review process. For the audit, you will need evidence that you ran it — a spreadsheet, a ticket, or a report from your IdP showing which accounts were reviewed and what action was taken.

Encryption at Rest (CC6.7)

CC6.7 covers the protection of data in transit and at rest. For Laravel, "at rest" means your database and any file storage.

Database encryption: Use RDS encryption at the storage layer (AWS) or equivalent. This is your foundation but is not sufficient on its own for sensitive fields.

Field-level encryption for sensitive data:

// app/Models/Customer.php
use Illuminate\Database\Eloquent\Casts\Attribute;

protected function taxId(): Attribute
{
    return Attribute::make(
        get: fn ($value) => decrypt($value),
        set: fn ($value) => encrypt($value),
    );
}

Laravel's encrypt() and decrypt() helpers use AES-256-CBC with your APP_KEY. For stronger key management, consider using AWS KMS or HashiCorp Vault to generate and rotate encryption keys, with Laravel's Encrypter configured to use a KMS-managed key.

Key management documentation: Auditors will ask how encryption keys are stored, who has access, and how rotation is performed. Write a one-page key management procedure before your audit begins.

Audit Logging (CC7.2, CC7.3)

CC7.2 requires that you monitor system components for anomalies and evaluate detected anomalies to determine whether they represent security events. CC7.3 requires that you evaluate security events and apply incident response procedures.

Laravel's logging system is a good foundation, but the default configuration does not capture enough for SOC 2:

// config/logging.php — add a dedicated security channel
'channels' => [
    'security' => [
        'driver'  => 'daily',
        'path'    => storage_path('logs/security.log'),
        'level'   => 'info',
        'days'    => 90,
        'replace_placeholders' => true,
    ],
],

What must be logged for SOC 2:

// app/Http/Middleware/AuditLog.php
namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;

class AuditLog
{
    public function handle(Request $request, Closure $next): mixed
    {
        $response = $next($request);

        if ($this->isSensitiveRoute($request)) {
            Log::channel('security')->info('sensitive_access', [
                'user_id'    => $request->user()?->id,
                'ip'         => $request->ip(),
                'user_agent' => $request->userAgent(),
                'method'     => $request->method(),
                'path'       => $request->path(),
                'status'     => $response->getStatusCode(),
                'timestamp'  => now()->toIso8601String(),
            ]);
        }

        return $response;
    }

    private function isSensitiveRoute(Request $request): bool
    {
        $sensitivePatterns = ['admin/*', 'api/users/*', 'api/billing/*', 'api/exports/*'];

        foreach ($sensitivePatterns as $pattern) {
            if ($request->is($pattern)) {
                return true;
            }
        }

        return false;
    }
}

Also log all authentication events (login, logout, failed login, password reset, MFA enabled/disabled) and all privileged actions (user role changes, account deletion, data export).

Change Management (CC8.1)

CC8.1 requires that changes to infrastructure and software are authorised, tested, and approved before deployment.

For Laravel teams, this typically means:

1. All code changes go through pull requests with at least one reviewer approval.
2. Automated tests run in CI before merge.
3. Deployment to production is automated (no direct git pull on production) and requires explicit approval for major releases.
4. Database migrations are reviewed as part of the PR process.

Document your deployment process in writing. Auditors will ask for evidence of PR approvals on changes deployed during the observation period. Make sure your GitHub (or GitLab/Bitbucket) repository has branch protection rules enforcing required reviews.

Continuous Monitoring (CC7.1)

CC7.1 requires that you implement detection tools and techniques to identify potential security vulnerabilities and events. This is where external monitoring becomes a direct control, not just a best practice.

External attack surface monitoring checks what an attacker sees when they look at your application: open ports, exposed admin panels, misconfigured headers, SSL/TLS issues, and known vulnerable dependencies. These are exactly the vulnerability classes that CC7.1 is designed to detect.

Evidence Collection Guide

Auditors work from evidence requests. Here is what you should prepare before the audit begins:

Access control evidence:

• A list of all system users, their roles, and the date access was granted.
• Documentation of your most recent access review (who reviewed, when, what was changed).
• Screenshots or exported logs showing MFA is enforced.
• Your offboarding checklist showing how terminated users are deprovisioned.

Change management evidence:

• Pull request records showing code review approvals for changes during the observation period.
• CI/CD pipeline logs showing tests ran before deployment.
• A record of production deployments with timestamps and approvers.

Monitoring and logging evidence:

• A sample of your security logs showing authentication events.
• Alerting configuration showing what triggers a notification and to whom.
• Any security incident records (even "no incidents found" is valid evidence).
• External scan reports showing vulnerability assessments were performed.

Encryption evidence:

• Your key management procedure document.
• Evidence that encryption is enabled on your database storage (AWS RDS encryption screenshot or equivalent).
• Configuration showing HTTPS enforcement and HSTS headers.

Vendor management evidence (CC9.2):

• A list of sub-processors (AWS, Stripe, SendGrid, etc.) and their own compliance certifications.
• Your vendor review process documentation.

Maintain a shared folder (Google Drive, Notion, or your compliance platform) during the observation period and add evidence as you generate it. Do not try to reconstruct twelve months of evidence in the week before the audit.

Common Pitfalls for Laravel Teams

Pitfall 1: Treating SOC 2 as a documentation project. SOC 2 Type II tests whether your controls actually operated. Writing policies is necessary but not sufficient. If your policy says you review user access quarterly but you have never done it, the auditor will find the gap. Build the controls into your operational calendar, not just your docs.

Pitfall 2: Missing evidence for the observation period start. The clock starts when the auditor selects the observation period start date. If you do not have logs from that date, you cannot provide evidence for that period. Centralise your logging before the observation period begins and ensure logs are retained for at least 12 months.

Pitfall 3: Scoping too broadly. The more systems in scope, the more controls you need to evidence. If your SOC 2 scope includes all of your infrastructure including internal tools, that is a much larger audit than scoping to just your production SaaS environment. Work with your auditor to define the narrowest scope that satisfies your customers.

Pitfall 4: Not testing your incident response process. CC7.3 requires that you have and exercise an incident response plan. Many teams write a plan but never run a tabletop exercise or simulate a security event. Auditors will ask whether you tested it. Run at least one tabletop exercise during the observation period and document the outcome.

Pitfall 5: Sharing database credentials between services. Least-privilege applies to service accounts too. If your background job queue, your web application, and your reporting service all share the same database credentials with full read-write access, that is a CC6.3 finding. Use separate database users with scoped permissions for each service.

How StackShield Supports SOC 2 CC6.x and CC7.x Controls

The Common Criteria around monitoring (CC7.1) and access control verification (CC6.6) specifically require detective controls that identify potential vulnerabilities before they are exploited.

External attack surface monitoring covers exactly this requirement. StackShield continuously scans your public-facing Laravel application for:

• Exposed configuration files and debug endpoints (CC6.6 — transmission protection)
• Missing or misconfigured security headers (CC6.6, CC6.7)
• Outdated dependencies with known CVEs (CC7.1 — vulnerability detection)
• Open admin interfaces without authentication requirements (CC6.1 — logical access)
• SSL/TLS certificate issues and weak cipher suites (CC6.7)

Each scan generates a timestamped report that you can store as audit evidence for your CC7.x controls, demonstrating that your detective controls ran throughout the observation period.

Conclusion

SOC 2 Type II is achievable for any Laravel application if you treat it as an engineering project rather than a paperwork exercise. The controls are largely things you should be doing anyway: enforcing MFA, logging security events, reviewing access, and monitoring for vulnerabilities.

The difference between passing and failing is whether your controls are implemented, documented, and evidenced throughout the observation period — not whether they exist on paper.

Start your SOC 2 preparation by auditing your current security posture. A free StackShield scan will show you the gaps in your external attack surface that most commonly become SOC 2 findings. Address those gaps, then focus on the operational controls: access reviews, change management process, and incident response rehearsal.

The audit is the last step, not the first. Build the controls, run them for six to twelve months, and the report follows naturally.