Compliance and cybersecurity, secure software, and AI systems.
SAGEN offers three service areas. They are distinct enough to sell separately and related enough that most substantial engagements draw on more than one.
| Area | What it delivers |
|---|---|
| Compliance and cybersecurity | Assess the current state, define controls, prepare for frameworks, and verify results |
| Secure software development | Build custom systems with security and obligations designed in |
| AI systems and automation | Put AI into a workflow with the controls that make it dependable |
They are not three departments handing work between them. One accountable team covers architecture through delivery, and the mix shifts with the problem.
The overlaps are where the value usually sits. A custom system for a regulated customer is a software engagement with compliance requirements written into the architecture. An AI system handling sensitive data is an AI engagement whose hardest questions are security questions. A compliance program frequently surfaces a system that needs rebuilding.
All three run the same four stages, which is what lets them combine without seams. A customer is not handed a different process when the work crosses an area.
This is not a menu where the customer picks one and gets a specialist team, and it is not a bundle where buying one requires the others. The right shape comes out of the discovery conversation.
When you present the three, lead with the customer's problem and let the areas follow. Listing all three first invites a prospect to decide which one they need before anyone has established what is actually wrong.
Three areas, one team, one way of working.
This service connects risk, architecture, engineering, and evidence so that security and compliance become part of how the organization operates rather than a separate paperwork exercise. A framework can define the objective, and the organization still needs controls that fit its systems, people, data, and risk.
Most customers arrive holding a requirement they did not choose. A large customer demands an attestation, a regulator applies, an insurer asks, or a deal stalls on a security questionnaire. They need to know where they stand, what to change, and how to prove it.
The work runs in four stages, covered in the next three chapters.
Typical engagements include security architecture and hardening guidance, cloud and application security reviews, readiness and remediation guidance for recognized frameworks, risk assessments and control programs, and audit evidence and technical documentation.
We assess systems we did not build. Existing applications, cloud environments, architectures, and operational processes are all in scope regardless of who originally built them.
Two limits matter and both are stated plainly to customers. We do not implement the changes in the customer's environment, and we do not perform the independent examination that a formal attestation requires. Implementation belongs to the customer or their IT provider. Attestation belongs to an accredited third party.
Those limits are not weaknesses to soften. They are what makes the assessment credible, and a buyer who has been sold otherwise by a competitor will recognize the difference.
We identify, explain, prioritize, and verify. The customer implements.
A readiness assessment establishes where an organization actually stands against the requirements that apply to it. It produces a scoped picture of the current state, the gaps between that state and the objective, and a prioritized view of what to address first.
Organizations rarely know this at the start. Policies exist without matching practice, controls exist without evidence, and nobody can say which gaps would fail an examination and which are cosmetic. Guessing is expensive in both directions: over-preparing wastes months, and under-preparing fails late.
The assessment covers the environment and the governance around it.
Scoping comes first and matters most. An unbounded scope produces an unusable report, so we establish which systems, data, and processes are in and out before assessing anything.
What the customer receives is a control mapping and gap assessment, a prioritized remediation plan, and a clear statement of the documentation and evidence each gap requires. Priority reflects risk and effort together, not severity alone.
A readiness assessment is not an audit, not a certification, and not a penetration test. It is a preparation exercise. It also is not a permanent legal conclusion about which regulations apply. Where applicability is genuinely uncertain, that is flagged for qualified review rather than decided in a questionnaire.
Set expectations on scope early in the conversation. The most common source of disappointment in this service is a customer who imagined a wider boundary than the one that was agreed.
We establish where you actually stand, and what it would take to close the distance.
Remediation support is the work of closing the gaps an assessment found. SAGEN defines what needs to change, why it matters, what the change must achieve, and what evidence will prove it worked. The customer or their IT provider makes the change.
A gap list on its own does not improve anything. Organizations stall between knowing and doing, usually because the finding is technical, the owner is unclear, or nobody has defined what "done" looks like. This service removes those three obstacles.
For each gap we specify the intended outcome rather than a single prescribed configuration, since the right implementation depends on the customer's environment. We identify who is accountable, what evidence would demonstrate the result, and how the item should be prioritized against the others.
Verification closes the loop. After the customer implements a change, the fix is confirmed against evidence rather than against someone reporting it complete. If the gap persists, it stays open.
We do not implement changes in the customer's environment. We do not hold credentials to their systems, deploy configuration, or take action on their infrastructure. The customer or their IT provider assesses the change, obtains approval, implements it, and retains rollback responsibility.
That boundary is the single most misdescribed part of this service. Say it early and without apology. A customer who believes SAGEN will perform the fix has bought something we do not sell, and the discovery happens at the worst possible moment.
A completed task is not a verified fix.
This is the work of getting an organization through a formal process: preparing the scope, the controls, the documentation, and the evidence that an examination or certification requires, and supporting the customer while it runs.
Preparation is where most of these efforts fail. The controls may be adequate while the evidence is scattered, the scope is unclear, or the documentation does not describe what the organization actually does. An examiner cannot accept "this is handled" without something to look at.
We help define the boundary of the system under review, design controls that fit the environment, organize the evidence into something an examiner can work through, and prepare the narratives and documentation the process expects. Where findings arise during the process, we explain what must change and what evidence will close them.
SAGEN does not certify anyone and does not perform the examination. For a service organization attestation, an independent licensed firm performs the examination. For a certification, an accredited body does. Our role ends at preparation and support.
This distinction is a credibility asset. An organization that both prepares a customer and audits them has a conflict, and buyers in this market know it. Being clearly on the preparation side is the correct answer, not a limitation.
Never say SAGEN certifies, audits, or attests. Say we prepare organizations for certification and support them through it. The difference is one clause and it is the difference between an accurate claim and a false one.
We prepare you for the examination. Someone independent performs it.
Customers name a framework long before they understand it. Knowing what each one actually is, in a sentence, is enough to have a credible first conversation and to recognize when someone has named the wrong one.
Three are actively offered.
| Framework | What it is |
|---|---|
| SOC 2 | An examination of a service organization's controls, performed by a licensed CPA firm. Common when customers demand assurance |
| ISO 27001 | An international standard for an information security management system. A management framework, not a technical product |
| NIST | United States guidance used to assess risk and prioritize safeguards. Alignment rather than certification |
Two distinctions employees get wrong. SOC 2 produces a report from an examination, while ISO 27001 produces a certificate from an accredited body. And NIST alignment is not a certification at all, so nobody is ever "NIST certified".
Beyond these three, privacy and financial-reporting regimes come up in scoping conversations, including European and California privacy law and United States financial-reporting obligations. Whether one applies depends on where an organization operates, what data it handles, and its corporate status.
Applicability is a legal question, not a checkbox. A customer requesting a certification has not established that a law applies to them, and a law can apply to a customer who never mentioned it. Where this is uncertain, it goes to qualified review rather than being settled in a form.
Do not tell a prospect which regulations apply to them. Explain what each framework is, ask what is driving the requirement, and route the applicability question to someone qualified to answer it.
Name the framework accurately, and never rule on what applies.
SAGEN designs and builds custom software: business applications, operational platforms, cloud systems, integrations, and the modernization of systems that have outlived their design. The work is shaped around how the organization actually operates rather than around what a product happens to support.
Off-the-shelf software is the right answer until workflows, data, integrations, or controls become specific to the organization. At that point the tool starts shaping the work, teams build spreadsheets around the gaps, and the cost moves from licensing to the operational drag nobody is measuring.
Common engagements include internal tools and business applications, customer and partner portals, operational and case management platforms, cloud architecture and modernization, system and data integrations, and workflow automation.
Discover defines users, workflows, data, constraints, integrations, and measurable outcomes. Design produces an architecture and delivery plan balancing speed, scale, risk, and maintainability. Deliver builds in stages with validation throughout. Operate documents the system, supports deployment, and transfers the knowledge the customer's team needs to run it.
The last stage is the one that gets cut elsewhere and is not optional here. A system the customer cannot operate is not delivered.
This is not staff augmentation and not a fixed catalog of products. We do not place developers into someone else's team, and we do not resell a platform with configuration on top.
Modernizing an existing system is in scope, as is improving software SAGEN did not build.
We build systems around the operation, and hand over something the customer can run.
Section 1.4 described security by design as a principle. This chapter is what it means concretely when a system is being built, because the phrase is worthless to a technical buyer without specifics.
Buyers hear "secure by design" from everyone. The ones worth winning will immediately ask what it changes about the work, and a vague answer costs more credibility than saying nothing.
Four things change.
Obligations are identified before architecture. Data sensitivity, regulatory duties, contractual commitments, and access boundaries are established during discovery, so the architecture answers them instead of being adjusted later.
Controls appear in the design. Identity and access, data protection, encryption practices, logging, and segregation are named decisions in the blueprint rather than implementation details left to whoever writes that module.
Validation runs during delivery. Testing and review happen against working increments, so a structural problem surfaces while it is still cheap.
Evidence is a deliverable. Documentation, test results, and control evidence come out of the build rather than being reconstructed afterward. This is what makes a system defensible to an auditor, a customer, or an insurer later.
This is not a guarantee that a system is secure, and no honest engineering company offers one. It is a way of working that makes the security position explicit and reviewable at each stage.
When a prospect challenges the phrase, do not repeat it louder. Give them the four specifics and let them judge.
Secure by design means the obligations are settled before the architecture, not audited after the build.
SAGEN designs AI systems around a defined business outcome, the available data, the people who use the result, and the controls required for dependable operation. The technology is chosen after those are established, not before.
Most organizations arrive with a demonstration that impressed someone and a gap between that and anything they could rely on. Useful AI needs reliable data, integration with real systems, human oversight, security controls, evaluation, and a way to monitor performance over time. Assembling those is the work.
Common engagements include AI-enabled business applications, knowledge assistants and enterprise search, document and data processing workflows, decision support and intelligent automation, private or controlled deployments, and governance and model assurance.
Define sets what the system should improve, who uses it, and how success is measured. Bound establishes data access, permitted use, human review, security controls, and unacceptable outcomes. Evaluate measures quality, reliability, latency, cost, and failure modes against representative work. Operate tracks performance, feedback, exceptions, and changes that affect the system.
Sensitive data is workable when the architecture, access controls, data handling, model selection, vendor terms, and monitoring are designed for the sensitivity of the use case. That is a design conclusion, not a default.
This is not model research, not a promise that any use case is feasible, and not automation of judgment that should stay with a person. Part of the value is telling a customer which of their ideas are not worth building.
We build AI that survives contact with real work, and say so when a use case will not.
Governance is the set of controls that make an AI system accountable: what it may use, who reviews its output, what counts as an unacceptable result, and how anyone would know if it drifted. Assurance is the evidence that those controls are working.
An AI system fails differently from ordinary software. It does not throw an error, it produces a confident answer that is wrong. Nothing breaks, so nothing alerts, and the organization finds out from the person who acted on it. That is why governance is a design input here rather than an operational afterthought.
Seven controls, matched to the impact of the system.
| Control | The question it answers |
|---|---|
| Permitted use | What is this system allowed to be used for |
| Data boundaries | What may it access, and what must it never see |
| Human oversight | Who reviews output, and before which actions |
| Evaluation criteria | What does acceptable quality mean, measurably |
| Access controls | Who can use it and on whose behalf |
| Logging | What happened, and can it be reconstructed |
| Monitoring | Is it still performing as it did at launch |
Controls are proportionate. A drafting assistant and a system informing a regulated decision do not need the same oversight, and applying the heavier set to both wastes effort while making neither safer.
This is not model certification, not a guarantee of accuracy, and not a claim that oversight makes an AI system safe to use unsupervised.
Governance is also the most persuasive part of an AI conversation with a cautious buyer. A vendor who leads with capability sounds like everyone else. A vendor who leads with failure modes sounds like they have done this before.
Governance is what separates an AI demonstration from an AI system.