Shared Security Responsibility Model

Security is a boundary, not a promise

Every cloud service divides responsibility with the people who use it, and most incidents happen where each side assumed the other had it covered. This page draws that line. It is the companion to our CSA CAIQ self-assessment: the questionnaire says what is in place, this says who owns each part.

The Three Parties

Three Layers, Three Owners

PaymentHood sits between the platform underneath and the integration you build on top. Each layer is somebody's job.

Microsoft Azure

Infrastructure provider

Physical and environmental security, host hardening, hypervisor isolation and platform redundancy — backed by Azure's own ISO 27001, SOC 1/2/3 and PCI DSS attestations. PaymentHood operates no facilities and no physical equipment.

PaymentHood

The orchestration service

Application security, tenant isolation, encryption of the provider credentials you give us, webhook signing, audit logging, and the availability of the payment API.

You

The merchant

Your own integration: how you store the API key we issue, who you grant console access to, whether your endpoint verifies our webhook signature, and any channel through which you collect payment details yourself.

Control Ownership

Mapped to CSA CCM v4

Primary owner for each of the seventeen Cloud Controls Matrix domains. Shared means the control only works if both sides hold up their end.

Microsoft Azure PaymentHood Shared with you
  • A&A Audit & Assurance PaymentHood
  • AIS Application & Interface Security PaymentHood
  • BCR Business Continuity & Resilience Shared
  • CCC Change Control & Configuration PaymentHood
  • CEK Cryptography, Encryption & Key Management PaymentHood
  • DCS Datacenter Security Azure
  • DSP Data Security & Privacy Lifecycle Shared
  • GRC Governance, Risk & Compliance PaymentHood
  • HRS Human Resources Security PaymentHood
  • IAM Identity & Access Management Shared
  • IPY Interoperability & Portability PaymentHood
  • IVS Infrastructure & Virtualization Security Shared
  • LOG Logging & Monitoring PaymentHood
  • SEF Security Incident Management Shared
  • STA Supply Chain Management & Accountability Shared
  • TVM Threat & Vulnerability Management PaymentHood
  • UEM Universal Endpoint Management PaymentHood

Datacenter Security is inherited: PaymentHood operates no physical equipment, so those controls are satisfied by Azure's own attestations rather than implemented by us.

Your Responsibilities

The Ones People Assume Are Ours

Nothing here is a surprise once it is written down. That is the point of writing it down.

The API key we issue you

It authenticates as your application. User self-registration and user-generated API keys are disabled by default, but the key you hold is yours to store safely and to replace if it is ever exposed.

Who you invite to the console

We enforce multi-factor authentication and check every permission server-side on every request. We cannot know which of your staff should be able to issue a refund.

Any channel where you take card details yourself

Card data reaches your provider directly and never passes through PaymentHood. If you also collect payment details some other way — over the phone, or on a form you built — that channel is yours to assess.

Your provider relationships

You hold the contract with each payment provider and settle directly with them. Their fees, their coverage and their compliance posture are theirs to state.

Acting on the webhooks we send

Every webhook is signed with HMAC-SHA256 over the timestamp and body. Your endpoint must verify that signature, and must never treat a browser redirect back to your site as proof that a payment succeeded.

Testing before you go live

Every account gets a sandbox with its own API keys, isolated from live data and running against your provider's test credentials. Proving your integration there — including that your endpoint validates our signature — is yours to do before you switch to live keys.

What you put in the fields we give you

Metadata and reference fields are stored as you send them. Do not place cardholder data or unnecessary personal data in them.

Stated Plainly

What We Do Not Do

A responsibility model that only lists strengths is marketing. These are the gaps, so you find them here rather than three weeks into a vendor review.

No independent audit

No SOC 2 report, ISO 27001 certificate or PCI DSS Attestation of Compliance exists for PaymentHood. Our CAIQ is a self-assessment, not a certification, and we say so on the register itself.

No independent penetration test

We run automated dependency and code scanning on every change, but no third-party penetration test has been commissioned to date.

No customer-managed keys

Credentials are encrypted with our key, not a key you supply or control.

No rotation of the master credential key

Individual secrets you control — your webhook signing secret, your provider credentials — can be replaced at any time from your dashboard. The master key that seals the credential store cannot currently be rotated without re-encryption.

Running a vendor review?

Send us the questionnaire. We answer it against this model rather than around it, and we will go further under NDA than we will in public — including on architecture and on our fraud signals.