Securisea Case Studies

Software developers who build payment infrastructure often think of themselves as vendors. The moment cardholder data touches their systems in flight, though, they are service providers under PCI DSS. That single distinction reshapes their compliance obligations, their enterprise sales pipeline, and ultimately their revenue.

This case study on PCI validation for software developers draws on several real Securisea engagements, consolidated into a single composite client we will call PayStream Technologies. Identifying details have been changed, but the pattern — the trigger, the scoping surprises, the remediation effort, the business outcome — is one we see repeatedly at cloud-native payment software companies.

Meet Example Client: PayStream

PayStream Technologies is a 65-employee fintech that builds a cloud-based payment gateway API. Annually, it processes 2.3 million transactions for roughly 100 merchant clients. On paper, the engineering team was running a tight shop: modern CI/CD, a respectable vulnerability management program, and an SDLC that most startups would envy.

The problem: three enterprise deals worth $600K in annual recurring revenue stalled in procurement. In each case, the prospect’s security team asked for a current PCI DSS Attestation of Compliance (AOC) for Service Providers. PayStream did not have one. They had been self-attesting against a Self-Assessment Questionnaire (SAQ) and assuming that was sufficient. It was not. Any organization processing, storing, or transmitting cardholder data on behalf of others operates at Level 1 as a service provider and must be validated by a Qualified Security Assessor (QSA).

Choosing a QSA

PayStream interviewed three Qualified Security Assessor Companies and selected Securisea. The decision came down to four things:

• Deep experience with cloud-native payment gateways and API-based architectures
• A two-track assessor model: an advisory team to work alongside PayStream through scoping and remediation, and an independent QSA team to perform the formal validation, with documented separation between them
• Membership in the PCI Security Standards Council’s Global Executive Assessor Roundtable (GEAR), which is the SSC’s formal engagement channel with the most active QSA firms
• References from comparable SaaS companies that had been through the same wall PayStream was now hitting

That two-track model matters more than it sounds. A single firm that holds the QSA qualification and can field both advisory and independent assessor resources avoids the coordination overhead of splitting the engagement across two vendors, while still producing an attestation that will hold up to card-brand scrutiny.

The Path to PCI Validation for Software Developers

Based on PCI DSS compliance timelines for similar complexity environments, here's how PayStream's  compliance journey might go:

Note: The table and findings shown are for illustrative purposes. Actual assessment scope varies by transaction volume, merchant level, and cardholder data environment complexity. The underlying PCI DSS security requirements apply uniformly to all entities.

Phase 1: Scoping and Gap Analysis

Scoping is not a deliverable Securisea hands over. It is a joint exercise, and it is where most of the learning happens. Securisea’s advisory team worked with PayStream’s engineering, infrastructure, and compliance leads to map every system that stored, processed, or transmitted cardholder data, every system connected to those systems, and every system that could affect their security. This defined the cardholder data environment (CDE) and, just as important, what sat outside it.

Because PayStream operates as a service provider, the scoping exercise also produced a Responsibility Matrix, the document that makes explicit which PCI DSS controls PayStream owns, which the merchant owns, and which are shared. This is a service-provider-specific artifact that enterprise customers will demand during their own assessments, and getting it right early saves months of back-and-forth later.

The gap analysis surfaced findings that were realistic for a company of PayStream’s maturity. Among the most consequential:

• A backlog of known vulnerabilities in third-party software components, with no formal inventory process to track them
• No automated code review integrated into the path to production
• SDLC documentation that described the team’s actual practice only loosely, and did not meet PCI DSS expectations for a service provider
• Production access privileges for developer accounts that exceeded what job function required
• Logging in place, but without the centralized review and alerting PCI DSS requires

Phase 2: Remediation

Examples of the remediation work PayStream completed, with Securisea’s advisory team providing interpretation and readiness guidance throughout:

• New change-control procedures with documented impact assessment, testing, and approval gates before any production release
• Centralized logging with automated review and alerting on security-relevant events
• Migration to TLS 1.2+ (TLS 1.3 where supported) across all in-scope data flows, with cryptographic key management formalized
• Least-privilege access review across the CDE, with multi-factor authentication enforced on all access paths
• Vulnerability remediation SLAs by severity, with a documented risk-based approach for the remainder

Phase 3: Testing and Readiness

Before the formal assessment, PayStream completed the testing PCI DSS requires at evidence level: internal vulnerability scans, external ASV scans by an Approved Scanning Vendor, and independent penetration testing covering both the application and network layers. Securisea’s advisory team then ran a readiness walkthrough against the full control set, identified the last remaining soft spots, and gave PayStream time to close them before the independent assessors began their work.

Phase 4: Formal Assessment

Securisea’s independent QSA team — distinct from the advisers who had been on the ground — conducted the PCI DSS assessment of PayStream’s CDE. Assessment activities included examining policies and evidence, interviewing personnel across engineering and operations, observing controls in action, and performing hands-on testing. Two findings emerged during fieldwork; PayStream remediated them within days, and the assessors re-tested before finalizing the report.

The final deliverables were the Report on Compliance (ROC) and the Attestation of Compliance (AOC) for Service Providers, which PayStream submitted to its acquiring banks and to the card-brand service-provider registries.

After the QSA signs the ROC, the PCI SSC itself often runs a quality-assurance review that generates questions and occasionally requests clarifications from the assessor. Having a QSA firm that has been through this loop many times — and that will stand behind its workpapers during that review — is the difference between a clean listing and a months-long delay. Securisea shepherded PayStream through the council’s QA process without the attestation being held up.

Results and Business Impact

Within 30 days of receiving the AOC, all three stalled deals — the $600K in blocked ARR — closed. Average enterprise deal size rose meaningfully as PayStream moved into conversations with prospects who had previously screened them out at the RFP stage.

The remediation work produced operational gains beyond the AOC itself: a sharp drop in production security defects, meaningfully less manual QA effort as automated checks absorbed the load, and a faster, more confident path to production.

Ready to Begin Your Compliance and Validation Journey?

If your company builds software that touches cardholder data in flight, you likely are operating as a service provider, whether or not you have called yourself one, and you may have an enterprise pipeline that will eventually depend on producing a current AOC.

Securisea has walked dozens of payment software companies through exactly this path. As a GEAR member firm with a deep QSA bench and a disciplined separation between advisory and independent assessment personnel, we can meet you at scoping and stay with you through the SSC’s final QA review.

If you’re interested in PCI validation for software developers, schedule a consultation with our team to discuss your timeline, scope, and approach.

Note: This case study presents a representative scenario for illustrative purposes based on typical PCI DSS compliance program processes and scope. Specific findings and business outcomes are representative of software company validation experiences. Actual validation requirements, costs, timelines, and results vary significantly by company size, existing security maturity, application complexity, and specific validation scope.

A SOC 2 examination and report enable SaaS companies to demonstrate to enterprise customers and investors that their controls meet the Trust Services Criteria for security, availability, and other categories relevant to their operations.

For educational purposes, we’ve put together this representative case study for CloudMetrics Analytics, a theoretical SaaS company whose enterprise clients and prospective clients are requesting SOC 2 Type 2 report to close business with them. This composite case study traces the path from strategic decision to final report issuance, to provide an idea of what SOC  2 examination for SaaS companies might look like.

Meet Example Client: CloudMetrics Analytics

Let's say CloudMetrics Analytics, a fictional 45-employee SaaS company, builds a cloud-based analytics platform that processes behavioral data and business metrics for 500 small business customers, generating $3M in annual recurring revenue.

The Problem: In this scenario, CloudMetrics leadership conducts market research during annual planning and discovers that a majority of enterprise vendor security assessments in their space require vendors to provide a SOC 2 Type 2 report. Their competitive analysis shows that similarly sized competitors moving upmarket already have SOC 2 Type 2 reports.

The Goal: Their VP of Sales realizes that to hit their three-year revenue goals, they need to increase annual contract value from $6K to over $15K. Mid-market customers represent that opportunity, but CloudMetrics anticipates that vendor security questionnaires and third-party risk assessments during due diligence will consistently ask for a SOC 2 Type 2 report. Without one ready, deals would either stall at the due diligence phase or require months more of delay while CloudMetrics completes the examination. Rather than waiting for lost deals to force their hand, CloudMetrics makes a strategic decision to pursue a SOC 2 Type 2 examination proactively.

Examination Roadmap

Based on SOC 2 Type 2 timelines for similar complexity environments, here's how CloudMetrics' journey might unfold. The first two phases—Readiness Assessment and Gap Remediation—are pre-examination activities that prepare the organization for the formal attestation engagement. The final three phases align with the examination process:

Note: This table represents a realistic path for SaaS companies with existing security controls that require design improvements to meet the applicable trust services criteria. Actual system boundaries, specified period, and activities vary significantly by the size and complexity of the service organization and its activities, existing control environment, subservice organization dependencies, personnel availability, and selected trust services criteria. This timeline is for illustrative purposes only.

Choosing a Service Auditor

Recognizing the need for appropriate competence and capabilities, CloudMetrics interviews three CPA firms and selects Securisea based on:

• Deep expertise in SOC 2 examinations for SaaS and cloud-native companies
• Experience with similar organizations navigating their first SOC 2 Type 2 engagement
• Clear communication style that helped teams understand requirements without impairing service auditor independence
• Consistent history of thorough examinations resulting in unmodified opinions for companies at similar stages

Phase 1: Readiness Assessment & Scoping

Securisea’s engagement team conducts a readiness assessment to advise CloudMetrics on which trust services criteria to include. Based on their principal service commitments and customer needs, and following discussion with Securisea’s service auditor, CloudMetrics’ management determines that they only need to include the Security category as of right now.

Throughout the engagement, Securisea provides ongoing advisory support, including criteria interpretation workshops, bi-weekly check-in calls, and a readiness review before the examination begins. Securisea also works with the tools CloudMetrics has already employed to document and remediate its compliance program.

CloudMetrics handles remediation implementation using internal engineering and security resources. Securisea maintains service auditor independence by providing advice, recommendations, and templates on what needs to be achieved, while ensuring that CloudMetrics’ management retains all decision-making authority over control design and implementation.

Key Deficiencies Identified in the Readiness Assessment

The readiness assessment identifies control deficiencies across the Security trust services criteria:

• Multi-factor authentication not yet deployed across all in-scope system components
• Access provisioning and deprovisioning processes lacking formal documentation
• Change management procedures requiring additional authorization and approval workflows
• Third-party vendors requiring risk assessments and updated contractual agreements
• Formal risk assessment process needing implementation
• Security monitoring and logging capabilities requiring enhancement

Phase 2: Gap Remediation

CloudMetrics implements a variety of controls designed to meet the applicable Trust Services Criteria and documenting their policies and procedures. Here is a sample of some of the controls implemented:

Logical and Physical Access Controls (CC6)

• Implements multi-factor authentication across all in-scope system components
• Creates formal access provisioning and deprovisioning policies and procedures
• Establishes quarterly user access reviews for all user accounts on in-scope systems

Change Management (CC8)

• Documents development and deployment processes aligned with the system development life cycle
• Implements testing and approval controls for system changes
• Creates change authorization policies with separate pre-development authorization and pre-implementation approval

System Operations (CC7)

• Implements vulnerability scanning with patch management processes under change management controls
• Enhances logging across infrastructure and application layers
• Deploys security information and event management tools
• Creates formal incident response program and procedures

Risk Management and Vendor Assessment (CC3, CC9)

• Implements formal risk assessment process identifying and analyzing risks to the achievement of service commitments
• Conducts risk assessments for vendors and business partners, tiered by risk level
• Updates vendor agreements with requirements for the scope of services, roles, compliance, and service levels
• Establishes a periodic vendor review process based on assessed risk

Phase 3: Examination Planning

With controls designed, implemented, and operating, Securisea formally accepts the attestation engagement and begins planning procedures. The service auditor assesses risks, identifies key controls to be tested, and works with CloudMetrics’ management to establish the specified period for the examination.

Securisea recommends a three-month specified period for this first-time Type 2 examination, providing sufficient time to demonstrate operating effectiveness while keeping the timeline efficient.

Phase 4: Performing the Examination

Throughout the specified period, CloudMetrics operates its controls as designed while Securisea’s service auditor performs procedures to test whether controls are operating effectively.

Evidence Collection

CloudMetrics’ designated compliance lead maintains the evidence that demonstrates control operation, including access logs, change tickets, vendor risk assessments, incident records, and training records. The company’s existing systems and processes naturally generate most of this evidence, making the collection process straightforward.

Tests of Controls

The service auditor tests controls by selecting samples from populations of control occurrences throughout the specified period. The service auditor performs inquiries of appropriate personnel across engineering, security, operations, HR, and executive management; inspection of documents and records; observation of the application of specific controls; and reperformance of selected controls.

Securisea identifies one exception related to a documented change that did not follow the complete change authorization and approval process due to an emergency situation. CloudMetrics provides a response in Section V of the report—Other Information Provided by the Service Organization—explaining the circumstances and corrective actions taken. This section is not covered by the service auditor’s opinion.

Phase 5: Forming the Opinion and Issuing the Report

After completing all tests of controls, including evaluation of the change management exception identified during testing, the service auditor issues an unmodified opinion, which is the best possible outcome. The opinion confirms that CloudMetrics' system description was presented in accordance with the description criteria, that controls were suitably designed, and that controls operated effectively throughout the specified period to provide reasonable assurance that service commitments and system requirements were achieved based on the applicable trust services criteria.

The final SOC 2 Type 2 report includes the independent service auditor's report, management's assertion, the system description, and the results of the service auditor's tests of controls. CloudMetrics' response to the identified exception appears as other information provided by the service organization.

Results and Business Impact

Immediate Outcomes

With Securisea's readiness assessment providing a clear remediation plan and the examination producing a SOC 2 Type 2 report, CloudMetrics removes a key procurement blocker and begins competing for larger deals.

Sales Progress

CloudMetrics closes its first $25K annual contract within 90 days of receiving the SOC 2 Type 2 report. Two additional mid-market deals close within the following quarter. Average annual contract value increases from $6K to $15K over the following 18 months as the company builds its mid-market sales motion.

Potential Financial Impact

CloudMetrics’ SOC 2 Type 2 report removed a key procurement barrier, contributing to upmarket revenue growth alongside pricing changes, product enhancements, and sales team development.

Operational Improvements

The remediation work informed by Securisea’s readiness assessment and criteria guidance produces operational improvements:

• Documented, repeatable processes that support company growth
• Significant reduction in time spent responding to security questionnaires, as the SOC 2 report addresses many common questions directly
• Improved incident response capabilities with a defined program covering classification, containment, mitigation, and communication responsibilities
• Enhanced vendor risk management, with structured assessment and monitoring of third-party risks

Key Takeaways and Next Steps

1. Understand Report Types: SOC 2 Type 2 reports provide an independent opinion on operating effectiveness throughout a specified period, offering a higher level of assurance than Type 1 reports, which address the suitability of design as of a point in time. Type 2 is what most mid-market and enterprise customers expect.
2. Choose the Right CPA Firm:You need a firm with relevant industry expertise, particularly with SaaS and cloud environments. Look for experience with companies at similar stages and documented approaches to maintaining service auditor independence while providing advisory guidance.
3. Build for Operations, Not Just the Report: The controls you implement should drive genuine operational improvements. The process requires documentation and operating effectiveness that benefits the entire organization beyond the examination itself.
4. Select Appropriate Trust Services Criteria: Security is the only required TSC for every SOC 2 examination. Unless clients demand additional categories, we recommend starting here. Organizations can always incorporate additional categories, such as Availability or Confidentiality, into future examination periods as service commitments evolve.
   

Ready to Begin Your SOC 2 Examination for SaaS Companies?

Securisea specializes in SOC 2 examinations for SaaS and technology companies. Our engagement team understands the unique challenges of cloud-native environments and can guide your organization through the process while maintaining the service auditor independence required by AICPA professional standards.

Schedule a consultation to discuss your system boundaries and approach.

Note: This case study presents a representative scenario for illustrative and educational purposes only. CloudMetrics Analytics, all personnel, timeline details, specific findings, and business outcomes are entirely fictional. This case study does not constitute professional services of any kind. Actual examination scope, selected trust services criteria, specified periods, the service auditor’s tests of controls and results thereof, and the service auditor’s opinion vary based on the service organization’s size, the nature of services provided, system complexity, organizational structure, subservice organization arrangements, regulatory environment, and principal service commitments and system requirements. The service auditor’s opinion provides reasonable assurance, not a guarantee of specific results. SOC 2 examinations are performed under the Statements on Standards for Attestation Engagements (AT-C Section 105, Concepts Common to All Attestation Engagements, and AT-C Section 205, Assertion-Based Examination Engagements), using the 2017 Trust Services Criteria (TSP Section 100) and the description criteria (DC Section 200).