CISA study materials
CISA study resources

The SaaS Contract That Never Went Through IT

CISA · Put your knowledge to work in context.

All case studies

The SaaS Contract That Never Went Through IT

A marketing director signs a three-year SaaS contract for a customer-data platform at USD 180,000 per year, charged to the department's discretionary budget. Because it falls under the USD 250,000 capital approval threshold, no board or IT review was triggered. The platform holds 1.2 million customer email addresses and five years of purchase history. IT learned of it only when the vendor requested firewall changes. The vendor's data-processing terms place backups in a region not approved under the company's data-residency policy, and no security assessment was performed. The CIO wants the contract cancelled. Marketing says the platform underpins a campaign launching in six weeks. The IT steering committee meets monthly and has no standing SaaS agenda item.

1. What is the primary governance failure? Be specific about which control broke, not just that policy was bypassed.

Read the worked answer

The threshold control is denominated in money when the risk is denominated in data.

The approval gate uses a USD 250,000 capital test. At USD 180,000 per year the contract is invisible to the gate, yet it exposes 1.2 million customer records and creates a cross-border data flow. Nothing in the process asked 'what data does this touch?' before signature.

Contributing failures, in order of significance:

  1. Risk ownership was never assigned. Marketing owns the budget line; nobody owns the information risk. The CIO's instinct to cancel is a symptom of that vacuum.
  2. No architectural or security intake. A platform holding customer master data and integrating with internal systems is by definition an IT dependency, regardless of cost.
  3. No register. Nobody can state how many such contracts exist, so the exposure cannot be quantified - this one was found by accident, via a firewall request.
  4. The steering committee has no standing agenda item, so the body best placed to arbitrate a cross-functional conflict between marketing and IT has no routine mechanism to see the issue.

Note what is not the primary failure: an individual disobeying a rule. The director followed the documented process. That is why the fix is process design, not discipline.

2. The CIO wants termination; marketing wants to launch. How should the steering committee decide, and on what criteria?

Read the worked answer

Termination is one option among several, and it should not be chosen by seniority. Frame it as a risk-acceptance decision with a deadline.

Criteria the committee should apply:

  • Data residency: can it be fixed? Ask the vendor to contract for in-region backups. If they will, the compliance breach is remediable within the contract. If they will not, that is close to disqualifying on its own, because it conflicts with a stated policy and possibly a legal obligation.
  • Security posture. Obtain the vendor's independent assurance report (SOC 2 Type II or equivalent) and read the exceptions, not the cover page. An unread report is worse than none - it creates false comfort.
  • Data minimisation. Does the platform need five years of purchase history and full email addresses, or can the extract be reduced? Reducing the data reduces the risk regardless of the vendor.
  • Exit cost versus remediation cost. Cancellation has its own costs: contractual termination penalties, campaign delay, and loss of the marketing capability. Those belong in the analysis rather than being asserted.
  • Time-box. If the decision is 'remediate', set conditions with dates that land before the campaign launch, and name the executive who formally accepts residual risk. Acceptance must be documented, not implied by silence.

The committee's job is to make the trade-off explicit and assign it, not to pick the loudest position. If the campaign launches on unresolved residency issues, the record must show who accepted that and when.

3. What single control change would most reduce recurrence, and what would you test in 12 months to know it worked?

Read the worked answer

A risk-based intake gate: any new third party that stores, processes or connects to company data requires review, regardless of contract value.

The trigger moves from spend to data and connectivity - the two attributes that actually create the exposure. Spend-based thresholds will always be gamed by disaggregation, and lowering the dollar figure simply moves the boundary rather than removing it.

The gate needs four components to function:

  1. A pre-signature step in procurement - the purchase cannot complete without an intake record. Procurement is the choke point because every vendor must be paid.
  2. Data classification question at intake, triaging to full security review only where warranted.
  3. A maintained register of SaaS in use, with owner, data categories and review date.
  4. Standing steering committee agenda item covering the register, exceptions and risk acceptances.

Twelve-month test:

  • Recompute the register independently - for example from accounts-payable vendor payments and from firewall/proxy logs of SaaS traffic - and compare to the register. Completeness is the assertion that matters; a register that lists only what was submitted proves nothing.
  • Sample 15–20 contracts signed in the period, including small ones, and verify an intake record preceded signature.
  • Inspect steering committee minutes for evidence the register was actually discussed with decisions recorded, not merely tabled.

If the register matches independent sources and pre-signature review is evidenced on a sample, the control is operating. If the register is clean but the proxy logs show unlisted platforms, the gate has been designed around the cooperative and will fail again.