Studio ↔ Partner: Who Operates What
Most trust pages on the web belong to SaaS operators. SpiceFactory is not a SaaS operator — we are a product studio that engineers software the partner runs. That distinction shapes which controls live with us and which live with the partner, and we name it here on the public page so the responsibility split is never ambiguous to a CISO clearing the engagement.
| Area | SpiceFactory operates | Partner operates |
|---|---|---|
| The studio's own environment | Identity, endpoints, source-control hardening, secret management, dependency & static analysis, training, HR security, vendor management, BCP for our delivery infrastructure, this trust portal. | — |
| Engagement codebase & SDLC | Secure-development practice, code review, change management, threat modelling, security regression, release sign-off, design-time data discipline. | Acceptance, deployment, and change-approval governance under the partner's release cadence. |
| Partner production runtime | — | Production infrastructure, key custody, production data, production uptime, production incident response, and the partner's own SOC 2 / ISO / HIPAA / FDA / PCI compliance obligations as the operator of the system. |
| Partner data in flight (during delivery) | Data-classification handling, least-privilege scoped access, no-production-data-in-design rule, synthetic / anonymised data for development & test, data return or destruction at engagement close. | Lawful basis for sharing the data, breach-notification obligations to data subjects, regulator-facing reporting. |
| Regulatory submission & certification | Records-of-construction (audit trail, electronic-records discipline, IEC 62304-aligned SDLC, requirements traceability, evidence retention) to support the submission. | Submission ownership and regulatory accountability as sponsor / operator. SpiceFactory does not sign as the regulated entity. |
| Subprocessors | The studio's own subprocessors (productivity, source-control, secret stores, this portal's hosting) — disclosed publicly at /policies/subprocessors.html. | Production-side subprocessors used by the partner's running system. |
What the register covers, and what it does not. The 113 controls SpiceFactory maintains describe how the studio operates — how we engineer software, qualify engagements, handle partner materials, train people, and govern the program. It does not describe how the partner operates the system in production; that is the partner's posture, on the partner's trust page, against the partner's auditor. We engineer to support that posture; we do not stand in for it.
How We Protect Partner Data
SpiceFactory is an embedded product studio. The software we co-create sits inside our partners' security boundary, and we operate the controls below — continuously — to keep that boundary intact.
Access Control
Role- and engagement-scoped least-privilege access governed by our Access Control Policy. MFA enforced for all production and partner-data systems. Quarterly user access reviews are performed by the Compliance Officer with reviewer sign-off retained in the compliance register. Off-boarding triggers access revocation within one business day, evidenced by the offboarding checklist.
Encryption
Data in transit protected by TLS 1.2 or higher; data at rest protected by AES-256 on the platforms we control. Endpoint full-disk encryption (FileVault) is required on every team-issued device and verified via the quarterly endpoint-security attestation that every team member signs against the laptop baseline. Secrets stored only in dedicated secret managers — verified by GitHub secret scanning and push protection.
Secure Development Lifecycle
Documented in our Secure Development Policy and Code Review Standards. Branch protection requires independent peer review before merge; emergency hotfixes follow the documented exception process and are reviewed after the fact. SAST, dependency scanning, and secret scanning run on every pull request. Threat modeling is performed for features handling regulated data; OWASP ASVS guides security test coverage.
Incident Response
Operated under our Incident Response Plan with four severity tiers and documented response timelines. Partner notification follows the contractual SLA (default: within 72 hours of confirmation; HIPAA breaches per 45 CFR §164.410). Every Sev-2 and above triggers a post-incident review with root cause, corrective actions, and reviewer sign-off retained in the incident record.
Personnel Security
Pre-engagement verification — identity, right-to-work, references, and where lawful criminal record checks — performed for all personnel in accordance with the employment law of the jurisdictions we operate in (United States and Serbia). All personnel acknowledge the Information Security Policy and complete security awareness training at hire and annually; engineers on healthcare engagements complete HIPAA-specific training before access is provisioned. Onboarding and offboarding follow documented checklists with completion logged.
Vendor & Subprocessor Management
Vendors with access to partner data or production systems are assessed before engagement against our Vendor Management Policy. Critical vendors are reviewed annually — SOC 2 / ISO 27001 reports requested where available, contractual security and breach-notification obligations confirmed. The vendor register and review history are maintained in the compliance tracker.
Capabilities in Operation
The studio operates a defined set of security capabilities. The platforms below are the current implementations of those capabilities; the practice — what we do and how we evidence it — is the control, and the tooling rotates per engagement when a partner mandates a different stack. Configuration evidence is collected on a recurring cadence and retained in the compliance register.
How This System Is Operated
The portal you are reading is the public face of a live trust system. Behind it sits our internal compliance register — the runtime where controls are owned, tested on cadence, and evidenced. Partners get the running record, not a snapshot.
A register, not a binder
Every control has a named owner, a test cadence, a last-test date, a next-test date, and attached evidence. Items moving out of currency are flagged on the operating dashboard the same day. The register is the source of truth — policy documents reference it, not the other way around.
Append-only audit trail
Every status change, evidence upload, access review, vendor review, and incident entry is recorded on an immutable audit log with actor, action, and timestamp. The log is queryable by leadership and surfaced to partner reviewers under NDA.
Continuous cadence, not annual cram
Access reviews quarterly. Vendor reviews on a tiered cadence by criticality. Policy reviews at least annually and on significant change. Risk and exception reviews on their own schedules. Items overdue are visible to leadership the moment they slip — not at audit time.
Built to exceed, not to pass
The control set is mapped to SOC 2 (2017 TSC), ISO/IEC 27001:2022 Annex A, the HIPAA Security Rule, FDA 21 CFR Part 11, and PCI DSS v4.0 (service-provider posture). We have chosen to operate the controls continuously rather than purchase a point-in-time attestation. Partner security teams are welcome to evaluate the live system directly.
“Compliance, run as a paperwork exercise once a year, doesn't make a studio safer — it makes a binder. We chose to operate the controls as a live system: every one of them has a named owner, a cadence, evidence on a clock, and a place on the audit log. Partner security teams who work with us get the running record — that is what trust looks like at SpiceFactory.”
Information Security Officer · HIPAA Security Officer (45 CFR §164.308(a)(2)) · accountable owner of the SpiceFactory trust program
security@spicefactory.co
Whole-Studio Scope
Security at SpiceFactory is a whole-studio discipline — not an engineering function operating in parallel to everything else. Every discipline carries register entries, named owners, and a cadence. The same control posture answers a partner CISO whether the question is about engineering, design, customer success, marketing, or how the engagement was qualified at intake.
Business development & intake
Pre-engagement risk classification (Standard / Health / Payments / Medical-device / Safety-critical / Sanctions) before partner data is shared. Partner due-diligence: entity verification, sanctions screening, regulatory-posture review. Master engagement contracts (MSA, SOW, NDA, BAA, DPA, reliance addenda) reviewed before signature.
Design & UX
Engagement-scoped design-tool access; partner brand and asset confidentiality; no real production data in design artefacts under any circumstance; accessibility as a shipping quality gate; privacy- and security-by-design checkpoints at every design phase.
Engineering
Capability-named, technology-agnostic — the practice applies across every stack we engineer in (Node, TypeScript, Python, Scala / Java, Android, iOS, embedded, hardware, ML). MFA on every identity, branch protection on every default branch, automated dependency vulnerability monitoring, static analysis, secret-leak protection, change management, threat modelling.
Quality
Test data discipline — production data never enters non-production tiers; representative-data patterns and partner-supplied anonymised extracts only. Defect-to-security-incident escalation triggers. Three-signature release sign-off (engagement lead + QA + VP Eng). Security regression automation per engagement.
Customer success
Documented post-signature handoff. Engagement-health cadence (monthly + quarterly, scaled by risk class). Named escalation chain with audit-log entries on every escalation. Partner-satisfaction survey at midpoint and close. Post-engagement closeout checklist (data return, destruction, access revocation) within 30 days.
Marketing
Every external piece — case study, blog, talk, social, demo — reviewed before publication for partner confidentiality, regulated-data exposure, framework-claim accuracy. Partner-reference subregister with written approval per public mention. Marketing-data privacy under the same lawful-basis discipline we ask partners for.
Growth
Minimum-viable, privacy-preserving telemetry on studio properties — cookieless first-party by default; third-party trackers behind a consent gate. A/B experimentation ethics: accessibility preserved across variations, allocation never uses personal data. Mar-tech access under quarterly review.
Leadership
Standing ISMS oversight body (CEO, GM, VP Eng, COO) with a quarterly meeting cadence, written record into the audit log, and a quarterly signed attestation snapshot. Annual BCP and incident-response tabletops with full executive participation. Annual board-level security and compliance review.
Roles & Accountabilities
Security responsibilities are assigned to named roles, approved by executive leadership, and documented in the Information Security Policy.
Leadership
CEO
Approves the Information Security Policy and security budget. Owns the risk register at the executive level and accepts residual risk on behalf of the company.
General Manager
Owns the policy framework and the control register. Coordinates quarterly access reviews, annual policy reviews, vendor reviews, and partner security reviews. Maintains the evidence trail.
VP of Engineering
Owns the Secure Development Policy, Code Review Standards, and Vulnerability Management Procedure. Approves engineering exceptions and signs off on production change requests.
Chief Operating Officer
Owns recurring compliance operations: control test execution, training completion, HR security, and physical/operational controls. Reports operational metrics monthly.
All Personnel
Engineers
Acknowledge the Information Security and Secure Development policies at hire and annually. Complete OWASP-aligned security training; HIPAA training prior to any healthcare engagement assignment. Access is granted only on assignment and revoked on rotation.
Design & UX
Trained in data minimization. Real partner or end-user PII / PHI is not permitted in design tools or prototypes. NDA executed and background check completed before access to partner materials.
Product & Project Managers
Scope and document access per engagement. Confirm security requirements at kickoff against the Engagement Security Addendum. Track engagement-level compliance tasks in the compliance register.
Sales, Marketing & Business Development
Acknowledge the Acceptable Use and Data Classification policies. Handle prospect and partner data per the Data Classification Policy. No access to engineering systems or partner code; endpoint encryption (FileVault) and screen-lock required by the laptop baseline and confirmed through the signed quarterly endpoint-security attestation.
Policy Framework
A documented policy set covers information security, data protection, incident response, secure development, HR security, vendor management, and HIPAA / FDA 21 CFR Part 11 alignment. Each policy is approved by executive leadership, version-controlled in Git, reviewed at least annually or upon significant change, and acknowledged by personnel at hire and annually. Available to partners under appropriate access controls.
Core Security
Information Security · Access Control · Password & Auth · Encryption · Acceptable Use
Operations
Change Management · Incident Response · BCP/DR · Vulnerability Mgmt · Risk Mgmt
Governance
Data Classification · Vendor Mgmt · Asset Mgmt · HIPAA Security · SDLC
People & Privacy
Remote Work & BYOD · Security Training · Subprocessors · Privacy Policy
Engagement Lifecycle Controls
Security controls applied across the partnership lifecycle, governed by the Engagement Security Addendum and the Onboarding / Offboarding Procedure.
1. Engagement Start
Mutual NDA and Engagement Security Addendum executed. BAA executed prior to any PHI access. Background checks confirmed for assigned personnel. Engagement-specific data classification, access scope, and security obligations documented in the kickoff record.
2. During Delivery
Access scoped to named personnel and the systems required for their role. Pull requests require independent review under the Code Review Standards. SAST and dependency scanning gate the pipeline. Production data is not used in development or test environments; synthetic or de-identified data is used in its place.
3. Team Rotation
Joiners complete engagement-specific onboarding before access is provisioned. Rotation-off triggers the offboarding checklist: access removed within one business day, evidenced by the completed checklist and a corresponding audit-log entry.
4. Engagement Close
Access revoked within one business day of close. Partner data returned or destroyed within 30 days per the Data Retention Policy and any contractual terms. Credentials and shared accounts rotated. A written confirmation of data disposition is provided on request and retained.
Framework Alignment
Our control set is mapped to recognized frameworks so partner auditors can evaluate our posture against standards they already use.
| Framework | Scope of alignment | Status | Documentation |
|---|---|---|---|
| Trust Services Criteria — Security, Availability, Confidentiality AICPA 2017 TSC, revised Points of Focus 2022 |
Common Criteria (CC1–CC9, Security) operated against on every engagement, plus Availability (A1) for studio delivery and the trust portal itself and Confidentiality (C1) for partner IP and engagement materials. Processing Integrity is added per engagement when SpiceFactory operates a partner-facing transactional system; Privacy is narrow-scope and applies only to controller-role data we hold directly (team HR, partner contacts, trust-portal access). | Operated against — not certified | TSC control mapping, policy set, operating evidence in the register |
| ISO/IEC 27001:2022 | Annex A controls (93 controls across organizational, people, physical, and technological themes). ISMS scope: SpiceFactory product studio operations and engagement delivery. | Aligned — not certified | Annex A control mapping, ISMS context and Statement of Applicability |
| HIPAA (45 CFR Parts 160, 162, 164) | Business Associate obligations under the Security Rule, Breach Notification Rule, and applicable Privacy Rule provisions. BAA executed prior to PHI access. | Operating program | HIPAA Security Program, BAA template, Breach Notification Procedure |
| FDA 21 CFR Part 11 | Controls supporting partner regulatory submissions: electronic records integrity, audit trails, e-signature requirements, and IEC 62304-aligned SDLC for software intended as a medical device. | Supports partner submissions | Electronic Records Policy, 21 CFR Part 11 control mapping, FDA Compliance Program |
| PCI DSS v4.0 | Service-provider alignment for partners with cardholder-data scope. SpiceFactory does not store, process, or transmit cardholder data as a standing service; where engagements engineer payment-handling code or operate payment-touching systems on a partner's behalf, our secure-development, key-management, access-control, logging, vulnerability-management, vendor-management, and training controls are mapped to the relevant PCI requirements so partners can rely on us under their PCI program. | Aligned — service-provider posture | PCI DSS control mapping, secure-development policy set, engagement-scoped reliance addenda |
| Evidence is refreshed per the control test cadence (typically quarterly for operating controls, annually for design controls). Stale evidence is flagged in the compliance register and remediated before the next quarterly review. Controls operate across every discipline of the studio — business development, design, engineering, quality, customer success, marketing, growth, and leadership — not engineering alone. | |||
Frequently Asked Questions
Common questions from partners and prospects about our security practices.
Working With Your Security Team
Embedded partnerships are how we work. Bring us your questionnaire, your control walkthrough, your pen-test scope, or your disclosed vulnerability — we will respond with the named owner and the live evidence, not a sales contact.
Contact security@spicefactory.co