Your GRC platform monitors the controls. We build them.
A fixed-scope engagement that deploys NIST AI RMF controls, SOC 2 evidence, and AI-infrastructure governance at the infrastructure layer. AI-native surfaces (MCP servers, agentic pipelines, LLM context boundaries) covered from day one. Built on NIST 800-53.
Engineered by Jeremiah Coakley, Principal Security Architect
Where this fits
The evidence layer of the ladder.
The controls FEDLIN builds on your node and across the AI you run become audit-ready evidence here: mapped to your framework, wired to your GRC platform, ready for the review. This turns what's running into what an assessor accepts.
Architecture and engineering
Two deliverables. Sold together or on their own.
Every FEDLIN engagement separates the architecture decision (which controls, where, and why) from the engineering that builds and runs them in your environment. Each stands on its own, and together they carry a requirement from design through proof.
Design authority
The architecture decision
Which controls actually satisfy the framework the deal runs on, and where each one belongs in the infrastructure. That mapping is the design decision every downstream build and every piece of evidence traces back to.
Engineering proof
What gets built
Control families deployed at the infrastructure layer, validated end to end in your GRC platform, with the AI-native surfaces covered from day one.
What's in front of you?
The engagement
One outcome: evidence an auditor accepts
The engagement is scoped to one thing: the controls your framework requires, deployed and enforced at the infrastructure layer, feeding evidence your GRC platform can present on audit day. Fixed scope, defined deliverable, priced on a scoping call.
Two things set the size of the work: how far your controls sit from passing the audit, and how much system there is to cover. The framework you are chasing shapes it too, whether that is SOC 2 or a NIST baseline.
Audit-ready evidence
You walk away with control families deployed, every platform integration validated, and an evidence package attributed to the specific controls it satisfies, at the fidelity and scope an auditor actually tests, confirmed before the audit window opens.
Vanta, wired to the real stack
Vanta is the primary delivery target, configured against your actual production environment, every integration validated to confirm active collection, custom monitors built where default coverage falls short. Drata and other platforms are supported the same way.
AI-native controls, built in
LLM context boundaries, MCP server access scope, and agentic audit logging are data-access and boundary controls an auditor is starting to test, mapped to ISO 42001 and NIST AI RMF, covered from day one.
Under the hood the program runs across six domains (governance and scoping, risk, control implementation, evidence and monitoring, audit readiness, and third-party risk), detailed below. They run continuously and feed each other; enter at whichever domain your prior work already covers, or stand the whole program up from a standing start.
GRC Engineering, SOC 2
From $5,000
From gap assessment to audit-ready evidence in Vanta
Gap assessment maps your control gaps against Trust Services Criteria. FEDLIN builds and wires the controls to evidence before your audit window. As a Vanta MSP partner, we configure the platform against your actual production environment, validate every integration, and build custom monitors where default coverage falls short.
AI-native surfaces (LLM context boundaries, MCP server access scope, agentic audit logging) are in scope across every domain, mapped to ISO 42001 and NIST AI RMF from day one.
Best for
- → Teams with an enterprise customer review or SOC 2 blocking a deal
- → Organizations building toward Type I or Type II audit readiness
- → Companies with Vanta or Drata already configured but failing controls
What this engagement covers
- →Gap assessment mapped to Trust Services Criteria (CC6.1, CC6.6, CC7.2, CC7.3 and adjacent controls)
- →IAM hardening, least-privilege, MFA enforcement, service account key elimination
- →Secrets management, vault deployment, rotation, hardcoded-credential closure
- →Infrastructure hardening, CIS benchmark compliance, automated scanning, drift detection
- →SIEM and runtime threat detection, log collection, alerting, CC7.2 evidence
- →Vanta wired to the actual stack, every integration validated, custom monitors for gaps
- →Client-owned Risk Register delivered at assessment close
What It Is
FEDLIN is the implementation and engineering layer, the part that decides whether a compliance program produces audit-ready evidence or just compliance activity. We configure the GRC platform against the actual environment, deploy control families at the infrastructure layer, build the evidence pipeline (manual or automated to match what each control requires), and validate every integration. The advisory layer (your vCISO, internal CISO, or external consultant) writes policy, owns the governance risk register, and drives POA&M decisions; we work from whatever they produce and execute the technical side. Where there's no advisory layer, we can carry the documentation too, and when the engagement starts with our own assessment, that documentation is the client-owned Risk Register it produces.
Engagement can start with whichever domain fits what already exists: build from a vCISO's completed gap assessment, or scope straight into evidence collection on a platform that's already configured. And where the architecture includes LLM integrations, MCP servers, or agentic pipelines, those surfaces are in scope across every domain: data-access, boundary-control, and audit-logging obligations that map to NIST 800-53 and to NIST AI RMF, at the fidelity a technically capable auditor now tests.
GRC Engineering vs. Vulnerability Remediation
GRC Engineering implements control families (the full IAM layer, the secrets management stack, the evidence pipeline) at the framework level. Vulnerability Remediation closes specific findings from a queue: post-pentest, post-incident, pre-M&A, audit backlog. They're complementary and often run in sequence: VR closes the finding inventory; GRC builds the program that prevents accumulation.
How a GRC program runs
The domains of a GRC program
A compliance program is not a line you walk once. Governance, risk, controls, evidence, audit readiness, and vendor risk run continuously and feed each other. FEDLIN operates the technical side of each. Enter where your prior work leaves off, or stand up the whole program from a standing start.
Where you have a vCISO or internal CISO, they own governance, policy, and risk decisions; FEDLIN executes the technical layer of each domain. Where you don't, we can carry the documentation too.
Governance & Scoping
Deciding what you answer to, and what you don't
Governance sets the boundary of the whole program: which framework you are certifying against, what falls inside the audit, and what genuinely does not apply. That last part carries real weight. A framework you don't actually fall under, once determined and documented, is scope removed before it drags the program down, not a gap an auditor has to chase later.
The advisory layer (your vCISO or internal CISO or external consultant) typically owns policy authorship and risk acceptance. FEDLIN works from whatever they produce and executes the technical side. Where there is no advisory layer, we can carry the documentation too. Either way the scope boundary is drawn against the actual architecture, including any LLM, MCP, or agentic surfaces that pull AI-governance obligations into the framework.
Works alongside your advisory layer
If you have a vCISO, fractional CISO, or external consultant handling policy, risk register, and POA&M, FEDLIN plugs in as the implementation and engineering arm. We take direction from whatever framework mapping they produce and execute the technical layer. No overlap, no scope conflict.
What You Get
- Framework selection and a documented scope boundary: what you are certifying against, and what genuinely does not apply, with the determination written down so an auditor reads reasoning rather than finding a gap
- Policy set authored or reviewed against the target framework, routed for approval with a named owner on each
- Program ownership mapped: who owns each control family, and the cadence on which posture gets reviewed
- A clean split with your advisory layer: where a vCISO or CISO owns policy and risk acceptance, FEDLIN executes the technical layer against their decisions
Risk Management
The Risk Register drives everything else
Risk is where the program gets its priorities. The assessment confirms whether controls are enforced in practice across the full environment, then every finding is ranked, costed, and mapped to the framework you answer to. That document, the Risk Register, is what makes every later decision purposeful: what to fix first because it is highest risk, what to defer because the framework doesn't require it yet, and what to build toward audit-readiness.
If your vCISO or another firm has already produced a gap assessment, we start there, ingesting it and re-mapping the findings into an implementation sequence. Where AI-native components are in scope they carry their own risk entries: an LLM integration is a data-access surface, an MCP server a boundary-control question, an agentic pipeline an audit-logging requirement, each mapped to NIST 800-53 and NIST AI RMF.
What Gets Assessed
Identity and access controls
Whether IAM policies across cloud and identity infrastructure are enforcing least privilege in practice, including service accounts, workload identities, and admin access paths.
Secrets exposure
Secrets appear in unexpected places, environment variables, config files, CI/CD pipelines, and in-context tool definitions. We confirm whether plaintext exposure exists across every surface in the environment.
Monitoring coverage
Whether security events are actually being captured across the environment. We confirm active monitoring coverage, that events are firing, routed, and surfaceable on demand.
Network perimeter
Whether the environment is reachable only via authorized paths, no unintended ingress, no origin servers bypassing edge controls, no internal services exposed to the wrong network segments.
AI and agentic context boundaries
Whether LLM tooling is accessing only what it's authorized to access, and whether that access is bounded by a control or just assumed to be limited by convention.
MCP server access scope
Tool definitions determine what an agent can reach. We confirm whether definitions are bounded to minimum necessary access and whether the boundaries are documented or implicit.
What You Get
From $5,000The Risk Register
Every finding ranked, costed, and mapped to the frameworks you answer to, each routed to the program that closes it. Yours to keep whether or not the work continues.
- Gap report with findings mapped to NIST 800-53 and NIST CSF controls, with secondary mapping to SOC 2 or ISO 42001, ready to feed into a GRC platform
- Prioritized remediation sequence, what to build first, what to defer, and why
- Control-to-finding mapping across every assessed surface
- Threat model covering the actual architecture, including AI-native components where present
- Or: ingestion of an existing gap report from your vCISO or prior engagement, findings re-mapped into the implementation sequence
The gap report is a prioritized remediation sequence: what to fix first because it's highest risk, what to defer because the framework doesn't require it yet, and what to build toward audit-readiness. It's the document that makes everything else in the program purposeful.
Control Implementation
Controls deployed and enforced at the infrastructure layer
Control implementation is FEDLIN's core. We build from whichever gap report exists, whether produced by our own assessment, handed over by a vCISO, or sourced from a prior engagement. The gap report determines what gets built and in what order; implementation turns that sequence into deployed controls with evidence.
Controls are built at the infrastructure layer and deployed: IAM policies updated, secrets moved out of environment variables into vault references, CI/CD pipelines instrumented with gates that block deployment on policy failure, monitoring configured to confirm active coverage. Each control produces an evidence artifact at implementation time, traceable to the build that deployed it.
Every control deployed here is instrumented to produce continuous evidence artifacts, linked to the specific pipeline run, deployment, and configuration state that satisfies the framework requirement.
Control Domains
The technical control families FEDLIN implements and maintains evidence for across engagements.
Access Rights & IAM
Least-privilege enforcement across cloud IAM, service accounts, workload identities, and admin access paths, over-provisioned roles remediated and documented.
Credential & Secrets Management
Vault integration replacing hardcoded credentials and environment variable exposure, rotation schedules confirmed, access audit trail established.
Secure SDLC
SAST gates built into the CI pipeline, static analysis findings routed as evidence artifacts, deployment blocking on policy failure.
Vulnerability Management
Scanning pipeline integration across containers, dependencies, hosts, and web applications, CVE findings routed as continuous compliance evidence. The scanning infrastructure and evidence automation live here; scoped finding closure lives in Vulnerability Remediation.
Security Logging & SIEM
Event collection confirmed active across the environment, events firing, routed, and surfaceable on demand with coverage validated per control.
Change Management
Deployment gate records structured as change management evidence, presync gate history and approval records linked to the controls they satisfy.
Network Configuration
Perimeter controls confirming the environment is reachable only via authorized paths, ingress exposure mapped and segmentation validated.
Encryption & Key Management
Key inventory documented, rotation schedules enforced, cipher configuration validated against framework requirements.
Backup & Disaster Recovery
Backup validation records produced automatically, restoration testing confirmed, RTO documentation current.
Incident Response
Response runbooks current, tabletop exercise records structured as evidence, timelines mapped to framework requirements.
Risk Management
Risk register maintained with treatment decisions documented, feeds into the vCISO's advisory layer or stands alone when there isn't one.
AI-Native Controls
MCP server access scope verified, LLM context boundaries confirmed, agentic pipeline audit logs structured, custom control logic built for the specific architecture.
What You Get
- IAM policies updated to enforce least-privilege access, over-provisioned roles remediated and documented
- Secrets management configuration validated, vault references replacing hardcoded credentials, rotation schedule confirmed
- Infrastructure security controls deployed as code: network segmentation, firewall policy, infrastructure-level audit logging, and runtime threat detection active and centralized
- Email trust and domain authentication controls deployed, enforcement posture visible and auditable
- Evidence artifacts traceable to specific builds, linked to the controls they satisfy, ready for auditor review
- Implemented controls mapped to specific framework requirements with evidence attribution
Evidence & Continuous Monitoring
The platform, wired to the real stack
This domain configures the GRC platform against the actual environment, validating every integration, building custom monitors where default coverage falls short, and linking CI/CD pipeline evidence to the controls it satisfies. Evidence collection runs in one of two modes depending on what the control requires. In manual upload, FEDLIN works directly with the end-client to gather and submit evidence artifacts. In automated pipeline, FEDLIN builds the collection mechanism so evidence flows continuously without manual intervention. AI-native infrastructure always requires custom logic: LLM context boundary enforcement, MCP access control verification, and agentic audit log collection.
Evidence collection keeps pace with the environment. As the stack evolves (new services, new integrations, new team members), FEDLIN updates the collection cadence and ownership model so the compliance platform stays current as the environment changes.
Automated evidence sources
- SIEM telemetry, event counts, alert summaries, agent health → Security Logging and Monitoring
- SAST output, static analysis findings by severity, scan pass/fail status → Secure SDLC
- DAST results, web application scan findings and remediation status → Vulnerability Management
- Container & dependency scan output, CVE counts by severity, clean/fail status → Vulnerability Management
- CI/CD deployment gate records, gate history, approval records, blocked deploys → Change Management
- Vulnerability scanner output, host and network findings by severity → Vulnerability Management, Network Configuration
- Backup validation records, completion status, restoration test results → Disaster Recovery Planning
- Secrets scan output, exposure findings per commit and build → Credential & Secrets Management
- Custom AI-native collectors, MCP access verification, LLM boundary enforcement, agentic audit logs → AI-Native Controls, custom logic built for the specific architecture
What You Get
- Your GRC platform configured against the actual production stack: every GRC tool integration validated to confirm it is actively collecting evidence
- Custom monitors built for coverage gaps: AI-native controls, non-standard infrastructure, and any domain where default platform coverage falls short
- CI/CD pipeline evidence linked to the compliance platform and attributed to the controls they satisfy
- Manual evidence uploaded directly to the platform, with defined owners, collection cadence, and a documented process
- Security toolchain telemetry structured as evidence artifacts: SIEM events, SAST findings, DAST results, CVE scan output, and deployment gate records mapped to the controls they satisfy
- AI-native control documentation covering agentic infrastructure, LLM context boundaries, and MCP access controls, attached and auditor-ready
- Audit export package validated against framework scope and reviewed for completeness before the audit window opens
- Ongoing monitoring cadence established, integration health, monitor coverage, and manual evidence ownership reviewed as the stack evolves
Audit Readiness & Assurance
A confirmed posture before the audit window opens
Two documents stand between a deployed program and a clean audit: the System Security Plan and the pre-audit readiness review. The SSP is written against the actual architecture, so every section reflects what is deployed. The vCISO or internal CISO typically owns the narrative and risk register; FEDLIN's contribution is the technical control documentation that feeds it: architecture docs, control-to-framework mapping, and AI-native component documentation that takes hands-on knowledge of the stack to produce accurately. Where a vCISO isn't in place, FEDLIN can produce the SSP directly. AI-native components are documented at the fidelity a technically capable auditor now tests: LLM context boundaries, MCP access scope, prompt-injection results, and agentic audit-log specifications, with NIST AI RMF mapping alongside NIST 800-53.
The readiness review is the validation layer between collection status and audit-grade evidence. It re-tests controls against current infrastructure state, confirms evidence is at the fidelity and scope an auditor will require, and surfaces findings before the audit window opens. The output is a pre-audit findings report with a disposition for every control in scope: pass, remediate before the window, or accept as a risk. An auditor testing a control against the SSP and finding a gap is a material finding; a document written against the actual infrastructure eliminates that class of gap before they arrive.
What You Get
System Security Plan & documentation
- System Security Plan covering all in-scope infrastructure and AI-native components
- Control-to-framework mapping for SOC 2, ISO 42001, or NIST CSF 2.0, every requirement mapped
- AI-native control documentation: LLM boundaries, MCP access scope, prompt injection test results, agentic audit log specifications
- Policy and procedure documentation for each control family
- Risk register with AI-specific risk entries and treatment decisions
- Architecture documentation with security properties annotated
Pre-audit readiness review
- Control-by-control infrastructure review against the target framework, covering every domain an auditor will test
- Pre-audit findings report: pass, remediate, or accept risk per control, with evidence status per finding
- Evidence artifacts attached per passing control, at the fidelity the auditor will require, confirmed before they arrive
- Remediation owners and timelines for any open findings, prioritized by audit impact and remediation sequence
- Updated control-to-framework mapping reflecting the current architecture and any framework changes since implementation
Third-Party & Vendor Risk
The vendors inside your boundary are part of the audit
A compliance program is only as sound as the vendors inside its boundary. Every subprocessor that touches in-scope data is part of the audit, and the framework expects you to know who they are, what they hold, and what contractually binds them. This domain builds and maintains that picture.
The work is a subprocessor inventory, data processing agreements executed against the vendors that need them, and a security review bar applied when a new vendor is onboarded. Where AI tooling sits in the stack, the subprocessor question extends to model and gateway providers: what data reaches them, under what agreement, and whether the data-processing terms actually cover the use.
What You Get
- Subprocessor inventory: every vendor that touches in-scope data catalogued, with what it processes and the trust basis for each
- Data processing agreements executed across in-scope subprocessors, tracked to the control requirement they satisfy
- A vendor security review bar applied at onboarding, so a new subprocessor clears a defined standard before it goes live
- The vendor register kept current as the stack changes: new integrations reviewed, retired ones removed
Framework Coverage
Every domain produces findings, controls, and evidence structured for the compliance framework your program targets. Supported frameworks include NIST 800-53 Rev 5, NIST CSF 2.0, and SOC 2 Type II, with secondary mapping to ISO 42001 as the AI-governance target. Artifacts from each domain are usable regardless of which audit you're working toward.
NIST AI RMF, mapped throughout the engagement
AI-native components (LLM integrations, MCP servers, agentic pipelines) are assessed against all four NIST AI RMF functions: GOVERN (organizational accountability, AI risk policies, oversight structure), MAP (risk documentation, system context, impact categorization), MEASURE (testing, performance measurement, bias and robustness assessment), and MANAGE (risk response, incident handling, residual risk monitoring).
Controls deployed in this engagement are cross-mapped: a single control can satisfy both an 800-53 requirement and an AI RMF subcategory simultaneously. Both mappings appear in every deliverable: the gap report, control documentation, SSP, and readiness package.
After the build
You cleared the gate. This keeps you cleared.
The engagement builds the controls and produces the evidence. Keeping them true as your stack changes (new frameworks, new integrations, and the AI and cryptography you ship next) is the embedded security architect: an ongoing seat the build grows into, or the way in when ongoing security is the need. It climbs one rung at a time.
The build grows into an ongoing seat with three tiers, set by what's at stake: Enablement (the security kept built and running, no gate in front of you), Assurance (a gate to keep clearing, a hand on every change, evidence audit-ready), and Stewardship (regulated or critical-consequence, governs the AI you run and owns your post-quantum migration). Reached by expansion, or entered directly when ongoing security is the need.
See the Embedded Security Architect program →Frequently Asked Questions
What does FEDLIN's gap assessment cover beyond standard scope?
FEDLIN's assessment confirms whether controls are enforced in practice across the full environment, including AI-native surfaces: LLM context boundaries, MCP server access scope, agentic pipeline audit logging, and cryptographic primitive exposure. For architectures with AI-native components, those surfaces are where the substantive findings tend to live.
We're approaching a funding round and stakeholders are asking about our security posture. Where does this program fit?
The gap assessment produces a specific, architecture-grounded answer. It maps what's actually deployed against your target framework, identifies what's exposed, and sequences what needs to be built. That document is the foundation for a credible conversation with stakeholders and the roadmap for the engagement that follows.
What's the relationship between NIST CSF and NIST 800-53 in this program?
NIST CSF 2.0 organizes security posture at the governance layer, structured around GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. NIST 800-53 is the technical control catalog that implements those functions at the infrastructure layer. This engagement uses both: NIST CSF 2.0 structures the posture picture; 800-53 is what gets assessed, implemented, and mapped to findings. SOC 2 and ISO 42001 both trace back to this foundation, so every artifact produced is usable regardless of which framework the audit targets. Engagements structured around NIST CSF 2.0 produce the same underlying evidence as those structured around 800-53. The control families map directly.
We have a vCISO. How does FEDLIN fit alongside them?
FEDLIN is the technical delivery layer. The vCISO owns the advisory work: gap assessment, policy authorship, risk register, POA&M decisions. We work from whatever they produce and execute the implementation: standing up the GRC platform, deploying controls at the infrastructure layer, building the evidence pipeline, and validating every integration against the running stack. We operate in our lane and coordinate directly with the advisory layer as the engagement requires.
Do we have to engage the whole program at once?
No, each domain is available as a standalone engagement where the prior work already exists. If your vCISO has completed the assessment and policy work, we scope directly into control implementation, evidence, or monitoring. If controls are already deployed and you need SSP documentation, we start there. Standing up the full program is the path when building from scratch; a single domain is the right scope when filling a specific gap.
We already have a compliance platform. Can you still help with evidence and monitoring?
Yes, this is one of the most common entry points. The platform surfaces the gaps; we own the technical layer that closes them. That means deploying the controls, wiring the evidence pipeline, and validating every integration so your dashboard reflects what's actually happening in the environment. Evidence can be uploaded manually (working directly with your team) or fed continuously via automated pipelines we build. Persistent failures on specific controls (CC6.1, CC7.2, CC8.1) are addressed at the source, by validating and redeploying the underlying infrastructure controls that those tests measure. If you have an existing finding inventory to work through before the program is operational, that's the scope of Vulnerability Remediation.
What does the compliance readiness review catch that ongoing monitoring misses?
Ongoing monitoring confirms that evidence is collecting. The readiness review confirms that the evidence collected is at the fidelity an auditor will actually accept, correct scope, correct retention period, correct attribution to the control being tested. A dashboard showing green controls and a pre-audit findings report are two different things. The readiness review produces the second.
What's the relationship between GRC Engineering and your other services?
GRC Engineering is the full program (gap assessment through evidence pipeline), built across the domains of a GRC program: governance, risk, control implementation, evidence, audit readiness, and vendor risk. For teams that need a specific surface addressed without the full program, Vulnerability Remediation handles scoped finding closure from a post-pentest backlog or pre-audit queue; Self-Hosted AI Security addresses the AI-specific attack surface as a standalone engagement; Edge Security covers edge hardening and domain trust controls. Each can be scoped independently or as a precursor to GRC Engineering. If a standalone sprint surfaces a broader program need (no control infrastructure, no evidence pipeline, no compliance framework mapping), GRC Engineering is the path forward.
Get to audit-ready evidence.
Book a scoping call. We'll review your current posture, find which domains you already have covered, and scope a fixed engagement to audit-ready evidence in your GRC platform, AI-native surfaces included.
From the Blog
From the field notes
Often scoped together
Related engineering, delivered on its own or folded in
Penetration Testing
Adversarial testing that validates the controls deployed, findings tied back to the control framework.
Vulnerability Remediation
Finding closure before the GRC program is fully operational. A scoped sprint works the prioritized queue, closing items with evidence the platform can ingest.
Self-Hosted AI Security
MCP server access scope, LLM context boundaries, and agentic pipeline audit logging.
Ready to clear the gate?
Tell us what's in front of you. We scope from there.