Built for regulated financial institutions
S-PRO helps banks, fintech companies, and other regulated financial institutions deliver software with security, resilience, compliance, and third-party risk requirements in mind.
ISO 27001
Certified information security management system.
ISO 27701
Certified privacy information management extension.
Swiss HQ
Headquartered in Zug, with delivery centres in Poland and Ukraine.
FINMA-licensed clients
Practical delivery experience with FINMA-licensed financial institutions.
S-PRO is a software engineering vendor, not a regulated financial entity. This page describes how we support client obligations, not certifications we hold on their behalf.
DORA and ICT third-party risk readiness
Financial entities remain accountable for their ICT third-party arrangements. Our delivery model is designed to align with that expectation: we provide the documentation, controls and contractual hooks your risk and procurement functions need to assess and monitor us as a provider.
Vendor risk assessment support
We complete security questionnaires, due-diligence forms and risk assessments, and answer follow-ups from your second line.
ICT service documentation
Scope of services, roles, locations of delivery and dependencies described clearly enough to feed your register of information.
Security and operational controls
Access management, change control, monitoring and incident handling operated under our ISO 27001-certified management system.
Regulatory and procurement evidence
Policy extracts, control descriptions and contractual clauses supplied during due diligence, where contractually applicable.
Subprocessors and subcontractor governance
Engagements are delivered by S-PRO teams. Where a subprocessor or subcontractor is involved, it is governed under the same controls as our own staff and disclosed to the client.
Approval and oversight
Subprocessors are assessed and approved internally before engagement and reviewed periodically thereafter.
Access limitations
Access is scoped to the specific systems and data a role requires, and revoked when the engagement or task ends.
Flow-down security requirements
Confidentiality, data protection and security obligations are passed down contractually to any party involved in delivery.
Change notification
Material changes to the subprocessor list can be notified in advance, with objection rights where contractually agreed.
Data residency and access-control model
Client environments stay under client control by default. Residency, isolation and access boundaries are agreed at contract stage and implemented as part of the engagement setup.
Data residency options
Solutions can be deployed to client-owned EU, Swiss or other regional infrastructure to meet residency requirements.
Environment isolation
Development, test and production environments are separated, with non-production data anonymised or synthetic where feasible.
Least privilege and RBAC
Role-based access is granted on a need-to-know basis, reviewed regularly and removed on role change or offboarding.
Production access restrictions
Production access is limited, approval-based and time-bound — and can be withheld entirely where the client operates the environment.
Logging and traceability
Changes and privileged actions are traceable to an individual through source control, ticketing and platform audit logs.
Incident notification and escalation path
Security incidents affecting a client engagement follow a defined path from detection to client notification. Notification timelines are set in the contract; we do not publish a fixed SLA here.
-
Detection and triage
Suspected incidents are logged, classified by severity and assigned an owner under our incident management process.
-
Client notification
Named client contacts are notified for incidents affecting their data or services, within the timeframe agreed in the contract.
-
Escalation path
Engagement lead, then delivery management, then the information security function and executive sponsor as severity rises.
-
Responsible contacts
A named security contact and deputy are assigned per engagement and recorded in onboarding documentation.
-
Communication and closure
Status updates during the incident, then a written summary with root cause and corrective actions where applicable.
-
SLA-driven response
Response and notification service levels can be committed contractually, including support for your own regulatory reporting deadlines.
Business continuity, exit plan and handover
Concentration and exit risk are standard questions in financial-sector procurement. Our engagements are structured so that you can move the work in-house or to another provider without a rebuild.
Business continuity
Distributed delivery centres, remote-capable working and continuity planning maintained under our management system.
Key-person and knowledge transfer
Shared ownership of critical areas, backup roles and structured onboarding reduce dependency on any single engineer.
Living documentation
Architecture, runbooks, environment and deployment documentation are maintained during delivery, not written at the exit.
Source code and infrastructure handover
Code, pipelines and infrastructure-as-code live in client-owned repositories and accounts wherever the client prefers.
Exit planning
An exit and transition plan can be agreed at contract stage, covering triggers, timelines, responsibilities and data return or deletion.
Vendor transition support
Overlap periods, walkthroughs and hypercare support for your internal team or an incoming provider.
Penetration testing and vulnerability management
Testing scope, cadence and provider are agreed per engagement. We support client-commissioned tests and can arrange independent testing where it is part of the contract.
Vulnerability management
Findings are tracked centrally with an owner, a severity and a target date, and reviewed until closure.
Dependency and security scanning
Automated dependency, secret and static analysis checks run in the pipeline so issues surface before release.
Penetration testing
We support third-party penetration tests on delivered systems and remediate findings as an agreed workstream.
Severity-based prioritisation
Critical and high findings take priority over feature work; lower severities are scheduled into the delivery backlog.
Remediation and retest
Fixes are verified, retested and reported back to the client, with residual risk documented where a fix is deferred.
Secure SDLC and AI-assisted delivery controls
AI accelerates our delivery, but it does not change accountability: every change is reviewed by a named engineer and passes the same pipeline controls as hand-written code.
Secure SDLC
Security requirements, threat considerations and testing are part of the delivery lifecycle rather than a pre-launch checkpoint.
Code review and change control
Peer review on every pull request, protected branches, and a traceable link from ticket to commit to release.
CI/CD security controls
Automated gates on build, test and scan results, with restricted permissions to promote to production environments.
Secrets management
Credentials are held in managed secret stores, never in source control, with rotation and scoped access.
Human review of AI-generated code
AI-assisted output is treated as a draft: an engineer owns, reviews and is accountable for every merged change.
Restrictions on client data in AI tools
Approved tooling only, no confidential or personal client data in prompts, and client-specific restrictions honoured where agreed.
Audit rights, evidence package and RFP contact
Supporting evidence can be shared under NDA during procurement or due diligence, where applicable. Audit and information rights — including support for supervisory requests — can be agreed contractually.
- Information security policies
- Architecture documentation
- SDLC and change-management documentation
- Business continuity information
- Penetration-test summaries, where available
- Subprocessor information
- Data-processing documentation
- ISO 27001 and ISO 27701 certification evidence
Or write to hi@s-pro.io with your RFP or questionnaire.