NIST RMF Roles for Startups

Index

• The Problem: Too Many Hats
• The NIST RMF Roles
• Conflicts of Interest: What Cannot Be Combined
• The 5-Person Company
• The 50-Person Company
• How KeibiSoft Helps

The Problem: Too Many Hats

NIST SP 800-37 defines over a dozen distinct roles for risk management. In a government agency with thousands of employees, each role gets its own person or team.

In a startup, you might have 5 people total.

At Omnio (50 people, acquired by IBM), I was the CISO. I was also an individual contributor writing security controls in Rust, designing cloud architecture, and coordinating pentests. At Krizo (5-10 people, acquired by Dataminr for EUR 6M), I was officially a "Software Developer" but effectively ran security. I landed every major client: Vodafone, Maersk, BCG, Palo Alto Networks, Fujifilm. All by handling their security questionnaires, writing policies, and proving we were trustworthy.

Different company sizes. Same reality: one person wearing many hats. That person was me.

This is not inherently wrong. NIST explicitly allows it. Their guidance states: "there may be differences in naming conventions for risk management roles and how risk management responsibilities are allocated among organizational personnel (e.g., multiple individuals filling a single role or one individual filling multiple roles)."

But there is a critical caveat: "Organizations ensure that there are no conflicts of interest when assigning the same individual to multiple risk management roles."

Some combinations are forbidden. Not by preference. By logic.

The NIST RMF Roles

Before we discuss what can and cannot be combined, here are the key roles from NIST SP 800-37r2:

Organization-Level Roles

• Head of Agency: Ultimate accountability for security and privacy. In a startup, this is your CEO.
• Risk Executive (Function): Organization-wide risk management perspective. Can be an individual or a committee.
• Senior Accountable Official for Risk Management: Leads the risk executive function. Aligns security with strategy and budget.
• Chief Information Officer: Responsible for IT planning, security oversight, and ensuring security programs are effective.
• Senior Agency Information Security Officer (SAISO/CISO): Primary security liaison. Administers security program. Reports on effectiveness.
• Senior Agency Official for Privacy: Ensures compliance with privacy requirements. Manages privacy risk.
• Chief Acquisition Officer: Ensures security requirements are in procurement and acquisitions.

System-Level Roles

• Authorizing Official: The only person who can formally accept risk. Approves systems to operate.
• Authorizing Official Designated Representative: Day-to-day activities on behalf of the AO. Cannot sign authorization decisions.
• System Owner: Responsible for procurement, development, operation, and maintenance of a system.
• Information Owner/Steward: Authority over specific information. Sets policies for its use and protection.
• Common Control Provider: Implements and maintains controls inherited by multiple systems.
• System Security Officer (SSO): Maintains security posture. Day-to-day security operations.
• System Privacy Officer: Ensures privacy compliance at system level.
• Control Assessor: Assesses whether controls are effective. Determines if they work as intended.
• Security/Privacy Architect: Designs security solutions. Ensures protection needs are addressed in architecture.
• Systems Security/Privacy Engineer: Implements controls. Part of the development team.
• System Administrator: Sets up and maintains systems. Implements technical controls.

Conflicts of Interest: What Cannot Be Combined

The Authorizing Official

The Authorizing Official (AO) is special. They are "the only organizational official who can accept the security and privacy risk to organizational operations, organizational assets, and individuals."

This role cannot be delegated in substance. The AO can have a designated representative to handle day-to-day activities, but "the only activity that cannot be delegated by the authorizing official to the designated representative is the authorization decision and signing of the associated authorization decision document."

In a startup, the AO is typically your CEO or a C-level executive. They sign off on risk acceptance. This is not a technical role. It is a business accountability role.

The Control Assessor

The Control Assessor determines if controls are "implemented correctly, operating as intended, and producing the desired outcome." This requires independence.

NIST is explicit: "The required level of assessor independence is determined by the authorizing official... Assessor independence is a factor in preserving an impartial and unbiased assessment process."

You cannot implement a control and then assess its effectiveness. You cannot be the system owner and the control assessor for that system. The person who built it cannot objectively evaluate whether it works.

Forbidden Combinations

What Can Be Combined

Many roles can safely be combined. The key principle: as long as you are not checking your own work, combinations are generally acceptable.

• CISO + Security Architect: Common and acceptable
• System Owner + System Security Officer: Acceptable in small organizations
• CIO + Risk Executive: Common at the executive level
• Privacy Officer + Security Officer: Acceptable if both skill sets are present
• Security Engineer + System Administrator: Common in DevSecOps teams

The 5-Person Company

At Krizo (5-10 people, crisis management SaaS, acquired by Dataminr for EUR 6M), everyone did everything. I was officially a "Software Developer" but I handled all security questionnaires, wrote all policies, coordinated pentests, and landed every major client: Vodafone, Maersk, BCG, Palo Alto Networks, Fujifilm.

Here is a realistic role allocation for a tiny startup:

For critical assessments, you need external help. This is where a fractional CISO or external assessor becomes valuable. They provide the independence you cannot create internally.

Practical Reality at 5 People

• CEO signs risk acceptance documents. They may not understand every technical detail, but they understand business risk. Brief them clearly.
• Developers cross-review. Code review is already standard practice. Extend it to control assessment.
• Document who does what. Even informal role assignments should be written down. Auditors will ask.
• Get external assessment for certification. ISO 27001 requires independent assessment anyway. Use this for your control assessment needs.

The 50-Person Company

At Omnio (50 people, industrial IoT, acquired by IBM), we had more structure than a tiny startup but still significant role overlap. Here is how I handled it:

My Roles as CISO

• Senior Agency Information Security Officer (SAISO): Ran the security program, reported to leadership
• Security Architect: Designed cloud security architecture, threat modeling with OWASP Threat Dragon
• Common Control Provider: Wrote the entire ISMS in LaTeX (auditors called it "the best they had seen"), implemented shared controls across all systems
• Systems Security Engineer: Hands-on implementation of Microsoft SSDLC, OWASP DevSecOps, OWASP ASVS
• System Security Officer: Day-to-day operations, incident response, pentest coordination

At Omnio (50 people, industrial IoT), I also read and implemented the full NIST 800-53 series for CMMC/DoD readiness. Not just the appendices. The whole thing. IBM wanted to push Omnio for DoD contracts, and I did all the legwork before the acquisition.

Roles I Delegated

Because I implemented controls, I could not assess them. I delegated assessment responsibilities:

• Authorizing Official: CEO. They signed off on risk acceptance. I briefed them on risk in business terms, they decided.
• Control Assessor: External auditors for ISO 27001. At Omnio, we got certified in 4 months. The auditors assessed what I built.
• Risk Executive decisions: CTO and CEO jointly for major risk decisions. I provided analysis and options, they decided.
• Privacy Officer: COO or legal, depending on the company. Privacy is not just technical, and GDPR required business input.

Realistic Role Distribution at 50 People

How KeibiSoft Helps

I have been the person wearing all these hats. At Krizo (acquired by Dataminr) and Omnio (acquired by IBM), I filled most of these roles while also writing code and closing deals. Now I help other companies do the same thing, faster.

Roles We Fill

The Independence Advantage

When your internal team implements controls, they cannot objectively assess them. This is not a suggestion. It is a NIST requirement.

KeibiSoft provides the independence you need. When I act as Control Assessor, I evaluate what you built. When I act as Security Architect, I design solutions that your team implements. The separation is maintained.

This is exactly what I did at Omnio (50 people) and Krizo (5 people). At both companies, I delegated the Control Assessor role to external auditors because I could not assess my own work. Now I can be that external assessor for you.

Scaling With You: 5 to 50 to 200

5-Person Startup

At 5 people, you cannot afford a full-time CISO. You probably cannot afford a full-time security person at all. I become your entire security function:

• Fractional CISO: Strategy, program oversight, executive briefings
• Security Architect: Design controls that fit your stack
• Control Assessor: Independent assessment for certification
• Common Control Provider: Write your policies and procedures
• Questionnaire handler: I close the deals your sales team brings

15-30 Person Scale-up

At this size, you might have someone doing security part-time, but they are also doing DevOps or engineering. I fill the gaps:

• Mentor your internal security champion
• Provide independent assessment (they implement, I assess)
• Handle complex questionnaires that would otherwise block deals
• Accelerate certification timelines (ISO 27001 in 90 days, not 12 months)

50+ Person Company

At 50 people, you might have a dedicated security person. I provide specialized expertise:

• NIST 800-53 implementation for federal contracts (CMMC, FedRAMP)
• Acquisition readiness (make security a feature, not a blocker)
• Architecture review for complex cloud environments
• Independent control assessment for audit cycles
• Post-quantum cryptography advisory

Conclusion

NIST RMF defines roles for a reason. Separation of duties prevents conflicts of interest. Independent assessment ensures objectivity. Clear accountability ensures someone signs off on risk.

Startups cannot have 17 dedicated security professionals. But they can follow the principles:

• Assign roles explicitly, even if one person holds many
• Never let someone assess their own work
• Make the CEO or equivalent the Authorizing Official
• Document role assignments for auditors
• Use external resources for independence where needed

Whether you have 5 people or 50, the question is the same: who does what, and are there any forbidden combinations? Answer that clearly, document it, and you have the foundation of a compliant security program.

Two companies I helped got acquired. Security was not a blocker. It was a feature. The role assignments were documented. The controls were assessed by independent parties. The documentation matched reality.

If you need help figuring out who should do what in your organization, or if you need an independent party to fill the roles your team cannot, get in touch.