SOC 2 Compliance for Customer Portals

What SOC 2 Is

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the American Institute of CPAs (AICPA). It evaluates how an organization protects customer data based on five Trust Service Criteria:

1. Security — Is the system protected against unauthorized access? (Required for every SOC 2 report.)
2. Availability — Is the system available for operation as committed or agreed?
3. Processing Integrity — Is system processing complete, valid, accurate, and timely?
4. Confidentiality — Is information designated as confidential protected as committed?
5. Privacy — Is personal information collected, used, retained, disclosed, and disposed of properly?

Security is mandatory. The other four are optional — you choose which criteria to include based on what’s relevant to your business and what your customers require.

Type I vs. Type II

• Type I — Evaluates whether your controls are properly designed at a specific point in time. A snapshot.
• Type II — Evaluates whether your controls are properly designed AND operating effectively over a period of time (usually 6-12 months). The real deal.

Type I is faster and cheaper. It proves you have the right controls in place. Type II proves those controls actually work consistently. Most enterprise customers want Type II.

Who Needs SOC 2

SOC 2 isn’t legally required. It’s market-required. You need it if:

• You serve enterprise B2B clients. Companies with security teams and procurement processes increasingly require SOC 2 before sharing data with vendors.
• You’re a SaaS company. If customers trust you with their data, they want proof you protect it.
• You handle financial data. Financial services clients have regulatory obligations that flow down to their vendors.
• You operate in professional services. Accounting firms, law firms, and consulting firms handling client data face increasing pressure to demonstrate security controls.
• You compete against SOC 2-compliant vendors. If your competitors have it and you don’t, you lose deals.

The tipping point: when a single lost deal due to missing SOC 2 costs more than getting compliant.

SOC 2 Requirements Mapped to Portal Features

Here’s what each Trust Service Criterion means in practical portal terms.

Security (CC — Common Criteria)

The foundation. Every SOC 2 report includes security.

Firewalls and network security

• Web application firewall (WAF) protecting the portal
• Network segmentation between portal components
• DDoS protection
• Intrusion detection/prevention systems (IDS/IPS)

Encryption

• TLS 1.2+ for all data in transit
• AES-256 or equivalent for data at rest
• Encrypted backups
• Key management procedures

Authentication and access control

• Multi-factor authentication for all administrative access
• SSO integration for enterprise customers
• Role-based access control with least-privilege principle
• Unique user accounts — no shared credentials
• Password policies aligned with current NIST guidelines

Monitoring and alerting

• Security event logging
• Real-time alerting on suspicious activity
• Regular log review
• Vulnerability scanning (automated, at least weekly)
• Penetration testing (at least annually)

Availability

Relevant if your portal has uptime commitments.

Uptime monitoring

• Real-time uptime monitoring and public status page
• Defined SLA (e.g., 99.9% uptime)
• Measurement and reporting of actual uptime against SLA

Disaster recovery

• Documented disaster recovery plan
• Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
• Regular DR testing (at least annually)
• Automated failover for critical components

Redundancy

• Multi-region or multi-availability-zone deployment
• Database replication
• Redundant load balancers
• No single points of failure

Capacity planning

• Performance monitoring and baselines
• Auto-scaling or capacity planning procedures
• Load testing

Confidentiality

Relevant if your portal handles data that customers designate as confidential.

Access controls

• Data classification scheme (what’s confidential, what’s not)
• Access restricted to authorized personnel only
• Access reviews (quarterly or more frequent)
• Offboarding procedures that revoke access immediately

Data protection

• Encryption of confidential data in transit and at rest
• Secure disposal of data when no longer needed
• Restrictions on copying or downloading confidential data
• Data loss prevention (DLP) controls

Third-party management

• Vendor risk assessments
• Confidentiality agreements with subprocessors
• Monitoring of third-party compliance

Privacy

Relevant if your portal collects personal information from individuals.

Notice and consent

• Privacy policy that describes data collection and use
• Consent mechanisms where required
• Cookie notices and opt-out options

Data minimization

• Collect only the personal information needed
• Retention limits — delete data when it’s no longer needed
• Regular data inventory reviews

Individual rights

• Mechanism for individuals to access their data
• Mechanism for individuals to request corrections or deletion
• Response within defined timeframes

If You’re Buying a Portal Platform

When you use a third-party portal platform, SOC 2 compliance is a shared responsibility.

Verify the platform’s compliance

• Request their SOC 2 Type II report. Read it. The auditor’s opinion, control descriptions, and any exceptions or qualifications matter.
• Check the report’s scope. Does it cover the specific services you use? A SOC 2 report for a company’s marketing website doesn’t cover their portal platform.
• Check the reporting period. SOC 2 reports cover a specific time window. An expired or outdated report means controls haven’t been recently verified.

Understand shared responsibility

The platform may be SOC 2 compliant, but your configuration can still create compliance gaps:

• Access controls — The platform supports role-based access, but you configured everyone as admin.
• MFA — The platform supports MFA, but you didn’t require it.
• Data handling — The platform encrypts data, but you’re emailing sensitive reports in plaintext.
• User management — The platform has deprovisioning tools, but you never remove former employees.

Your SOC 2 auditor will evaluate your controls, including how you configure and use the platform. The platform’s compliance doesn’t automatically make you compliant.

Review subprocessors

Your portal platform likely uses other services: cloud hosting (AWS, GCP, Azure), email delivery, monitoring, analytics. These are subprocessors.

• Request a list of subprocessors
• Understand what data each subprocessor can access
• Verify that critical subprocessors have their own SOC 2 reports
• Monitor for subprocessor changes (most platforms notify you of changes)

If You’re Building a Portal

Building a custom portal means you own the entire compliance scope.

Infrastructure requirements

• Cloud provider — Use a major provider (AWS, GCP, Azure) with their own SOC 2 compliance. This gives you a compliant foundation.
• Infrastructure as Code — Manage infrastructure with Terraform, CloudFormation, or similar. This creates auditable, repeatable deployments.
• Environment separation — Separate development, staging, and production environments. Production access should be restricted and logged.
• Network security — VPCs, security groups, WAF, DDoS protection at the infrastructure level.

Logging and monitoring

SOC 2 auditors want evidence that your controls work. That means logs.

• Application logs — User actions, authentication events, errors, data access
• Infrastructure logs — Server access, configuration changes, network events
• Centralized logging — Aggregate logs in a SIEM or log management platform (Datadog, Splunk, Elastic)
• Retention — Retain logs for at least 12 months (longer for some industries)
• Alerting — Automated alerts for security events, anomalies, and failures
• Regular review — Documented process for reviewing logs (not just collecting them)

Policies and procedures

SOC 2 isn’t just technical controls. You need documented policies:

• Information security policy
• Access control policy
• Incident response plan
• Change management policy
• Vendor management policy
• Data classification and handling policy
• Business continuity and disaster recovery plan
• Risk assessment methodology
• Employee security awareness training program

These aren’t shelf documents. Auditors will check that policies are followed in practice, not just written.

Penetration testing

Annual penetration testing by a qualified third party. The test should cover:

• External network testing
• Web application testing (OWASP Top 10)
• API testing
• Social engineering (optional but increasingly expected)

Findings must be documented and remediated on a defined timeline.

Preparing for a SOC 2 Audit

Phase 1: Readiness assessment (1-2 months)

Evaluate your current state against SOC 2 requirements:

• Identify which Trust Service Criteria apply
• Document existing controls
• Identify gaps between current state and requirements
• Prioritize remediation efforts

Many companies hire a SOC 2 readiness consultant for this phase. Cost: $5,000-$20,000.

Phase 2: Remediation (2-6 months)

Close the gaps identified in the readiness assessment:

• Implement missing technical controls
• Write or update policies and procedures
• Deploy monitoring and logging
• Train employees
• Start collecting evidence

This is usually the longest and most expensive phase. The scope depends entirely on your starting point.

Phase 3: Type I audit (1-2 months)

An auditor evaluates your controls at a point in time. This is optional — you can go directly to Type II — but many companies start with Type I to validate their controls before committing to a longer observation period.

Phase 4: Observation period (3-12 months)

For Type II, the auditor observes your controls operating over a period. During this time:

• Follow your documented policies consistently
• Collect evidence of control operation (logs, review records, training records)
• Address any issues promptly
• Don’t make major changes to controls mid-period without consulting your auditor

Phase 5: Type II audit (1-2 months)

The auditor reviews evidence from the observation period, tests controls, and issues the report.

Total timeline

• Fast track (Type I only): 3-6 months
• Standard (Type I then Type II): 9-18 months
• Direct to Type II: 6-12 months

Cost

Audit costs

• Type I audit: $10,000-$40,000
• Type II audit: $20,000-$80,000
• Annual Type II renewal: $15,000-$60,000

Cost depends on the scope (number of Trust Service Criteria), complexity of your environment, and the audit firm.

Remediation costs

Highly variable depending on your starting point:

• Compliance automation platform (Vanta, Drata, Secureframe): $10,000-$30,000/year. These platforms automate evidence collection, monitor controls continuously, and streamline the audit process. For most companies, they’re worth it.
• Technical remediation: $0-$100,000+ depending on gaps. If you already have solid security practices, remediation is minimal. If you’re starting from scratch, expect significant investment.
• Policy development: $0-$15,000 if using templates and internal resources, more if using consultants.
• Ongoing maintenance: $5,000-$20,000/year for monitoring, evidence collection, and policy updates.

ROI calculation

SOC 2 is expensive. But calculate the cost of not having it:

• Deals lost because prospects require SOC 2
• Longer sales cycles due to custom security questionnaires (SOC 2 answers most questions upfront)
• Higher insurance premiums without demonstrated controls
• Increased breach risk without formalized security practices

For most B2B portal companies serving enterprise clients, SOC 2 pays for itself within the first year through unlocked deals.