Available
Regulatory Integration Blueprint
Sets out the application boundary, the data classification, the requirements, who owns which control, what evidence is expected, and the plan for putting it all in place.
Regulation ready
Enterprise software built for compliance from the first Blueprint.
Ferrite builds regulation-ready enterprise software and delivers it through your own environment and your own control framework. Before any of it is built, we start with a Blueprint, the plan that maps out how your application will work and what it has to satisfy. The Blueprint settles your requirements for identity, access, data, security, releases, monitoring, evidence, retention, and recovery, and it does so before the work moves to the Anvil, where the application is actually built.
You keep production authority and your business data inside your own boundary, and we supply and license the control foundation the application is built on. Because we remain the platform licensor and your service provider, we still expect to go through your vendor risk and software supply chain review, the same as any other provider you work with.
What makes enterprise software compliant?
Compliance comes from the whole operating system around the application.
Software supports compliance through many things at once: its architecture, how it is configured, the environment it runs in, the people around it, the policies they follow, the evidence it produces, and the way it is actually used from day to day. What we deliver is the part that belongs to the software itself, the application-level controls, the configuration points, the documentation, and the evidence interfaces that sit inside the application boundary.
We call this regulation ready because the software arrives prepared for your compliance process rather than claiming to complete it for you. You keep interpretation, policy, control operation, risk acceptance, and the final compliance determination, all of which stay where they belong, with your team.
We supply and license the control foundation your application is built on, you own the application itself along with the decisions about how it is controlled, and we keep ownership of the closed-source platform that makes all of it possible.
Why ownership changes the compliance model
With most SaaS, the vendor owns and operates the production system, so your job is to review that vendor, accept the architecture it has chosen, and lean on contracts and attestations for a great deal of the operational control you cannot see for yourself.
With Ferrite:
- The customer controls the production cloud or environment.
- The customer controls identity, credentials, production approval, and business data.
- The application can connect directly to the customer's security and evidence systems.
- Ferrite access can be limited, monitored, and revoked under customer policy.
- End Ferrite Care and the customer-owned application continues with the licensed Frame, Core, and integration versions already deployed.
- The Ferrite platform license remains active while at least one Ferrite application remains in operation.
- Frame, Core, and integration source code remain proprietary and are not provided or exposed to the customer.
We remain a technology licensor, and in many cases an important service provider, inside your vendor-risk and software-supply-chain processes. What we do not do is own your application, your infrastructure, or your business data.
You will find the full ownership and license boundary stated in the footer of every page.
The common control foundation
Seven application-level control areas come built into the platform and arrive with every application we deliver. Each one gives you configuration points to set for yourself and produces an evidence output you can route straight into your own compliance systems.
Controlled external communications
Every connection to an outside system passes through Core, the licensed layer we build and maintain that carries your integrations. Credentials, authorization, connector behavior, data movement, logging, and evidence all live in that one governed place, so you get a single point to control and to draw evidence from, while the code behind it stays protected.
Evidence produced
Connection and data-movement record
Operates inside your control boundary
Enterprise identity
Works with the identity provider, single sign-on, multi-factor login, role model, user lifecycle, and privileged-access rules you already have in place.
Evidence produced
Access event
Operates inside your control boundary
Least-privilege authorization
Supports role-based access, separation of duties, tightly scoped service identities, periodic review, and the approval paths you define for yourself.
Evidence produced
Approval record
Operates inside your control boundary
Encryption and secrets
Supports encryption both in transit and at rest, key management you approve, isolated secrets, regular rotation, and configuration that stays specific to each environment.
Evidence produced
Key and rotation record
Operates inside your control boundary
Governed releases
Every release can be traced back to an approved request, reviewed code, automated tests, security results, documentation, a signature, your own approval, and a way to roll it back if you need to.
Evidence produced
Signed release manifest
Operates inside your control boundary
Evidence and auditability
Produces structured events and records that feed straight into your logging, SIEM, audit, GRC, and evidence-retention systems.
Evidence produced
Audit event stream
Operates inside your control boundary
Monitoring and recovery
Supports health monitoring, alerting, encrypted backups, tested recovery procedures, agreed recovery objectives, and incident response that stays in your hands.
Evidence produced
Backup test, alert record, recovery result
Operates inside your control boundary
Plug into the client's framework
Map the foundation into the requirements that apply.
The Blueprint works out which frameworks apply to you, along with your internal policies, your data classifications, how critical the system is, who owns which control, and what evidence everyone will expect to see.
From there, the Application Blueprint maps the software foundation into those requirements. Depending on the scope of your application, that can take in programs and obligations associated with:
- SOC 2 Trust Services Criteria
- ISO/IEC 27001 information-security management
- ISO/IEC 42001 AI management
- HIPAA-regulated workflows: planned specialized delivery profile
- Financial-services control environments
- Government or contractual security requirements
- Industry-specific and customer-specific control frameworks
SOC 2 and ISO certifications or attestations apply to the organization and the defined scope that actually goes through the relevant independent review. We publish our own current assurance status separately, and mapping to a framework does not, on its own, hand you an attestation or a certification.
Frameworks the control foundation can support
One control foundation, mapped into the frameworks you already operate under. The scope, the review, and the final determination stay with you throughout.
SOC 2
Trust Services Criteria
The application-level technical controls, configuration points, and evidence outputs can be mapped into the criteria your examination scope covers. The examination itself stays with you and your CPA firm.
ISO/IEC 27001
Information-security management
The control foundation can be mapped into your information-security management system and its Annex A control set, within the boundary you define for the application.
ISO/IEC 42001
AI management
We build software with AI kept under human review, with recorded requests, signed changes, and named ownership at every step. Those records can be mapped into your AI management requirements for the application.
Productized regulatory engineering
We offer a set of defined regulatory engineering packages. Each one covers application controls, mapping, documentation, and evidence, and it stays within that scope rather than growing into an open-ended compliance program you never asked for.
Available
SOC 2 Control Integration and Evidence Pack
Maps and implements the application-level technical controls you need to bring your customer-owned application into your SOC 2 environment. We deliver the documentation and evidence outputs we have agreed on, and you and your CPA firm keep responsibility for the examination and the report itself.
Available
Customer-Specific Control Mapping
Maps the application foundation into a client, contractual, industry, or assurance framework you name, once we have confirmed that the framework can genuinely be supported within the application boundary.
Planned
HIPAA-Regulated Workload Enablement
Applications that handle protected health information need a specialized profile for ePHI flows, technical safeguards, business-associate implications, cloud services, third parties, documentation, and security evaluation. We are still finishing the delivery model, the contractual boundary, the reference architecture, and our risk position for this work, so the package remains planned for now.
What we deliver is the agreed application engineering, the documentation, the mapping, the evidence outputs, and one technical handoff session. Managing the independent assessment, obtaining the certification or attestation, administering your policies, running continuous compliance operations, keeping evidence over time, and open-ended remediation all sit outside the package.
Shared responsibility
Because the application runs in infrastructure you control, the set of controls is naturally split between us, and we write that split down together before any delivery work begins.
Ferrite delivers
- Application architecture and technical control implementation
- Build, test, review, signing, and release evidence
- Application documentation and control mapping inputs
- Integration points for identity, logging, monitoring, evidence, and recovery
- Agreed operational services performed under customer authority
The customer controls
- The production environment and business data
- Applicable regulatory interpretation and risk acceptance
- Identity authority, access approval, and user governance
- Production approval and change authority
- Retention, incident response, business continuity, and control ownership
- The final configuration and use of the application
Defined together
- The system boundary
- Control ownership and inheritance
- Evidence delivery and retention
- Service-provider access
- Incident roles
- Recovery objectives
- Transition and termination procedures
Every change we make is recorded from end to end.
A Spark, which is what we call a single governed change to your live application, keeps a record of the whole path it travels: the original request, the review of its impact, the approval to proceed, the build, the tests, the security review, the signature, your acceptance, the release, and the result once it is running.
We produce the agreed application evidence as the software changes, and you keep it, administer it, and present it through your own compliance program, just as you would for any other system of record.