Security work that
holds up in audit.
Application security, identity and access, secure SDLC, and compliance work for SOC 2, HIPAA, PCI-DSS, and ISO 27001. Built into the way the system runs, so the evidence the auditor asks for is already in place when they arrive.
Why security and audits go sideways.
In most programs, security sits next to engineering instead of inside it. The team builds, a review at the end surfaces findings, and the last six weeks before launch turn into patching and writing policy memos no one will read. The audit version of this is the same pattern in slow motion: evidence reconstructed from Slack threads and old tickets the week the auditor walks in.
What works in practice is less ambitious than it sounds. Threat modeling done while the design is still on a whiteboard. Access reviews on a calendar, not a fire drill. Logging and configuration captured by the platform rather than collected by hand. Change management that tells you who approved what, and when. None of it is novel — it is the discipline of treating security work as engineering, with the same rigor around tests, reviews, and rollback.
Apollo runs this work as engineering. We sit with the team, fix what is broken, and leave the controls, evidence, and runbooks in a state someone else can maintain. The audit becomes a walkthrough of how the system already operates.
The end-of-cycle review. Findings that needed addressing six months earlier land six weeks before launch. The choices left are shipping late or shipping with known gaps documented in a risk acceptance memo no one is happy with.
Evidence collection. Configurations, access reviews, change records, log retention — most of it can be produced by the system if it is set up to do so. Reconstructing it by hand is the most expensive line item in any audit, and the one that slips first.
An auditor is testing what the system does, not what the policy says it does. When the two drift apart, the conversation gets long. Keeping them in sync is an engineering job, not a documentation job.
Five shapes the work takes.
Most engagements land in one of these patterns. Each one maps to controls in the relevant framework, ships with the evidence the framework expects, and is set up so the team that inherits it can keep it running after we are gone.
Application Security & Secure SDLC
Threat modeling at design time, security review on the PRs that matter, SAST and DAST wired into CI, dependency and secrets scanning, and a security backlog that sits next to feature work instead of in a parallel system no one looks at. The point is fewer surprises in the last quarter before launch.
Identity & Access Governance
SSO and federation, RBAC or ABAC modeled against the actual application, OAuth and OIDC done correctly, privileged access with break-glass procedures, and quarterly access reviews that produce evidence on the way through. Zero-trust principles applied where they pay off, not as a marketing posture.
Compliance Engineering
SOC 2, HIPAA, PCI-DSS, ISO 27001, and NIST 800-53 translated into specific technical controls — not policy documents. Evidence collection set up inside operations: configurations, access records, change tickets, log retention. Most controls end up cheaper to run once the plumbing is in place.
Assessments & Remediation
Architecture review, threat models on existing systems, gap assessments against the framework in scope, and a remediation plan prioritized by exposure and effort, not severity scores. Written deliverables your team can act on directly. No slide decks left behind.
Data Protection & Key Management
Encryption at rest and in transit. KMS with proper key rotation. HSM-backed roots where the data class warrants it. Secrets management that does not break the deploy pipeline. Tokenization and field-level encryption for sensitive records. PII handling that holds up under HIPAA Safe Harbor and equivalent regimes. Everything wired to a key inventory so the next access review or auditor question is a five-minute answer, not a week of forensics.
Security work, layered into the SDLC.
Simplified for clarity, but it tracks how the work actually distributes across design, build, deploy, and operate. The evidence pipeline sits in the operate layer because that is where most programs lose ground — controls exist, but the proof that they ran does not.
Authorization that leaves a trail.
Access decisions and audit records on the same path
A simplified version of an access-control function for protected health information. The authorization check and the audit record sit on the same code path. You cannot grant access without producing the log entry — by construction, not by convention.
When an auditor asks how you know unauthorized access did not happen, the answer is a record for every attempt, granted or denied, with the user, the resource, the purpose claimed, and the policy decision. That is the kind of thing that takes one query to produce, not three weeks.
import { authorize, audit, AccessDeniedError } from "@apollo/security" import { z } from "zod" // Every PHI read flows through here. The audit log is the evidence. const PHIRequest = z.object({ patientId: z.string(), purpose: z.enum([ "treatment", "payment", "operations", ]), requestedFields: z.array(z.string()), }); export async function readPatientRecord( request: z.infer<typeof PHIRequest>, user: User, ) { // 1. Authorize. Returns the minimum permitted field set. const decision = await authorize({ subject: user, action: "read", resource: `patient:${request.patientId}`, purpose: request.purpose, }); if (!decision.allowed) { audit.log({ event: "phi.access.denied", user: user.id, patientId: request.patientId, reason: decision.reason, }); throw new AccessDeniedError(decision.reason); } // 2. Read only the fields the policy permits. const allowedFields =intersect(request.requestedFields, decision.permittedFields); const record =await db.patient.read(request.patientId, allowedFields); // 3. Emit the evidence record. audit.log({ event: "phi.access.granted", user: user.id, patientId: request.patientId, fields: allowedFields, purpose: request.purpose, }); return record }
Four phases. Evidence accumulating throughout.
Apollo's engagement model, applied to the failure modes specific to security and compliance work. Each phase produces working software and the evidence record auditors will look for, in that order.
Map the system. Find the gaps.
The system, the data flows, the controls already in place, where they fall short against the framework in scope. You leave this phase with a written gap assessment, a prioritized remediation plan, and a clear view of what is in scope and what is not.
Controls, identity, evidence plan.
Threat models for systems in scope. Architecture-level controls. The IAM model. Cryptographic boundaries and key inventory. The evidence collection plan, written so the team and the audit function can both work from it.
Controls into the SDLC.
Code review tooling, SAST and DAST in CI, IaC scanning, secrets handling, audit logging plumbed through to retention. Two-week iterations. Each control ships with its tests, its runbook, and the evidence record it produces.
Run it, then hand it over.
Detection live, response runbooks written, vulnerability management on a cadence, access reviews on a schedule, evidence pipeline producing records. Handover includes documentation a successor team can read, not just the people who built it.
The shortlist we work from.
What we deliver against. The selection on any given engagement depends on the framework in scope, the system's risk profile, and the team that will operate it after we leave. We will say why in the proposal — and we will say so when we think a tool is the wrong fit.
Frameworks & standards
Security tooling
Identity & cryptography
All product names, logos, and brands are property of their respective owners. Listed for identification purposes only. Apollo Technologies is not affiliated with, endorsed by, or sponsored by any of the companies named above.
Tell us about the work.
A paragraph is plenty. The system or program in scope, the framework, the timeline, what you already know is broken. We reply within one business day — either with a 30-minute call to dig in, or with a straight "this is not the right fit, here is who you should call instead."