Third-Party Cyber Risk Assessment — Solstice Capital × Stellar Technologies

Independent portfolio project based on a simulated assessment involving fictional organizations.

Executive Summary

Solstice Capital, a fictional financial institution, is considering Stellar Technologies, a fictional fintech service provider, for a payment-related business function. The assessment evaluates whether the available third-party assurance materials provide a sufficient basis for onboarding. The review considers a SOC 2 Type II report, an unresolved high-risk penetration testing finding, and the vendor's business continuity and disaster recovery readiness.

The central finding is that the existence of security documentation does not, by itself, demonstrate that a vendor meets the institution's requirements. In this scenario, the SOC 2 report does not cover the complete period for which Solstice needs assurance. A high-risk security finding remains open without sufficient retest evidence. Separately, the available recovery evidence does not establish that the payment service could be restored in accordance with Solstice's operational expectations.

Assessment decision: Withhold onboarding approval pending sufficient supplementary assurance, verified security remediation, and satisfactory disaster recovery validation. This recommendation does not establish that the vendor is permanently unsuitable; it identifies the evidence and risk conditions that must be addressed before authorization is reconsidered.

Business Context and Scope

Solstice Capital depends on third-party technology services to support business operations. A vendor supporting a payment-related function could introduce cybersecurity and service continuity exposure beyond the vendor's own environment. Solstice therefore needs to evaluate not only whether Stellar maintains a control program, but also whether that program provides adequate assurance for the proposed service and its business impact.

The assessment is limited to a simulated pre-onboarding review. It considers the supplied scenario's control assurance, security testing, continuity evidence, and decision requirements. It does not represent direct testing of a deployed vendor environment, an independent SOC 2 audit, or a real contracting decision.

Assessment Methodology

The review uses an evidence-based third-party risk approach. First, it identifies the intended service and the potential consequences of security or operational disruption. Next, it assesses the relevance, coverage, and limitations of available assurance evidence. Finally, it evaluates whether unresolved findings and missing validations leave risks above the level that should be accepted for onboarding.

The assessment distinguishes between a control being documented, a control operating during a particular reporting period, and a control being sufficiently validated for Solstice's requirements. This distinction is important because external assurance reports and vendor representations have defined scopes. They cannot automatically resolve questions outside the periods, systems, or criteria assessed.

Key Findings

SOC 2 Type II Reporting-Period Gap

A favorable SOC 2 Type II report may provide useful information about controls tested during its stated examination period. It does not automatically establish control operation outside that period. In the scenario, the available report leaves a coverage gap relative to the period Solstice needs to evaluate.

Solstice should request supplementary evidence addressing the uncovered period, such as an appropriate bridge letter or other relevant, supportable control evidence. Any supplementary material should be evaluated for scope, credibility, and the specific assurance it provides. The gap should remain open until the evidence has been reviewed rather than being treated as closed by the report's favorable result alone.

Unresolved High-Risk Penetration Testing Finding

The scenario includes a high-risk penetration testing issue that has not been sufficiently validated as remediated. A statement that the underlying issue was fixed is not the same as evidence demonstrating that the corrective action works.

Before accepting closure, Solstice should obtain remediation details and appropriate retesting or independent validation evidence. The remaining risk should be assessed in relation to the proposed service, relevant exposure, compensating controls, and Solstice's risk appetite. Until validated, the finding should be tracked as unresolved.

Business Continuity and Disaster Recovery Gap

Security assurance alone does not establish that a service will remain available or recover adequately after disruption. For a payment-related function, recovery capability is a significant consideration because downtime could affect operational commitments and downstream processes.

In the scenario, the available continuity documentation is insufficient to demonstrate the recovery readiness Solstice requires. Solstice should request evidence of a relevant disaster recovery exercise and evaluate the results against its recovery objectives, dependencies, limitations, and incident communication expectations. Policy documentation without a suitable test result should not be treated as proof of operational readiness.

Risk Evaluation and Decision Rationale

The outstanding issues affect different dimensions of third-party assurance. The reporting-period gap limits confidence in ongoing control operation. The unresolved high-risk finding raises questions about the effectiveness of security remediation. The continuity gap prevents Solstice from concluding that the proposed service can recover adequately following disruption. Treating these issues separately helps avoid a misleading overall judgment based solely on the presence of a favorable external report.

The final onboarding recommendation is deliberately conditional on verification. Solstice should not accept residual risk based on planned corrective actions alone. Each open issue needs an identifiable owner, suitable evidence, and a documented evaluation before the institution reconsiders approval. Where a risk cannot be reduced or validated to an acceptable level, the decision should be escalated through the appropriate governance process rather than implicitly accepted.

Remediation and Validation Priorities

Close the assurance coverage gap

Identify the precise period not covered by the SOC 2 Type II report and obtain evidence appropriate to that period. Confirm that the supplemental evidence relates to the relevant services and controls. Document any remaining limitations rather than interpreting a bridge document as equivalent to a full independent audit.

Validate the high-risk security fix

Request the finding's remediation record and retest results, including whether the original issue can still be reproduced and whether relevant compensating controls are necessary. Update the risk assessment based on validated results, not vendor assurances alone.

Demonstrate recovery capability

Obtain evidence of a disaster recovery exercise relevant to the payment service. Review whether the test demonstrates recovery within Solstice's defined expectations and identifies dependencies or unresolved deficiencies. Document any additional conditions necessary for onboarding.

Reassess before authorization

Once the evidence is available, reassess the remaining exposure, record any exceptions, and obtain the appropriate approval. Until that review is complete, the recommended status remains onboarding withheld.

Supporting Artifacts

Reflection

This case study illustrates why third-party risk assessments require organization-specific judgment. Framework alignment or a favorable assurance report can help establish confidence, but it cannot substitute for evaluating a vendor against the actual service requirements and risk tolerance of the institution. Security controls and operational resilience must be considered together when a vendor supports a potentially critical business function.

The decision to withhold onboarding reflects the information available in the scenario. It is not a claim that the vendor necessarily lacks security capability. The governance responsibility is to identify what remains unproven, request appropriate evidence, and avoid accepting risks before those conditions have been evaluated.