Book a demo →
Security Assessment

What Is Security Assessment and Authorization (SA&A)?

The discipline that decides whether a system is allowed to carry real work — and who is accountable when it does

Zeeshan MahmoodSecurity Assessment, Architecture & AI ·8 min read
Security AssessmentGovernment of CanadaRisk & Compliance

A system is finished. It works, it has been tested, and somebody asks the question that stops the meeting: is it secure?

Nobody can answer yes honestly. Nobody wants to answer no. So the conversation drifts into a list of things that were done — there is encryption, there is MFA, there was a penetration test in the spring — and the release happens anyway, on the strength of a general feeling that enough was probably done.

Security assessment and authorization replaces that feeling with something a person can sign.

The question is never whether a system is secure. It is how much risk it carries, who knows that, and who is accepting it.

What SA&A Is#

Two activities, bound together.

Assessment is a structured evaluation of whether the security controls a system is supposed to have are actually implemented and actually working — not documented, not planned, working.

Authorization is a formal decision, by someone with the standing to make it, to operate the system given what the assessment found.

Neither half is sufficient alone. An assessment nobody acts on is a document. A decision made without an assessment is a guess wearing a signature.

The two halves of security assessment and authorization Two panels side by side. The left panel, assessment, answers what is true: a structured evaluation of whether the controls work. It produces evidence that is gathered and traceable, and findings together with the risk that remains. It is carried out by an assessor who is independent of delivery. An arrow labelled the package carries its output to the right panel, authorization, which answers what will we accept: a decision to operate the system given what was found. It produces a decision that is signed, dated and possibly conditional, and accountability that can be pointed to. It is made by an authorizer senior enough to carry it. Neither half is sufficient alone: an assessment nobody acts on is a document, and a decision without an assessment is a guess. TWO ACTIVITIES, ONE OUTCOME ASSESSMENT What is true? A structured evaluation of whether the controls work. PRODUCES Evidence, gathered and traceable Findings, and the risk that remains CARRIED OUT BY An assessor, independent of delivery AUTHORIZATION What will we accept? A decision to operate the system, given what was found. PRODUCES A decision — signed, dated, conditional Accountability that can be pointed to MADE BY An authorizer senior enough to carry it THE PACKAGE Neither half is sufficient alone: an assessment nobody acts on is a document, and a decision without an assessment is a guess.
Figure 1: Two activities, one outcome. The assessment establishes what is true; the authorization decides what the organization is willing to accept.

Scroll sideways to see the full diagram →

Why It Exists#

Because systems carry risk to people, and somebody has to own it.

A payroll system that fails does not inconvenience a database — employees are not paid. A case management system with weak access control does not leak records in the abstract — it exposes the people described in them. ITSG-33 puts the accountability plainly:

The authorizer's role is to authorize the use of the information system to support organizational objectives. By means of this authorization, the authorizer assumes responsibility for relying on the information system and therefore accepts the risks associated with doing so.

ITSG-33 Annex 2 § 3.1.1

Authorization is not permission granted by a process. It is a person assuming responsibility.2 In the Government of Canada that accountability runs from the Policy on Government Security5 through the risk management activities ITSG-33 builds on top of it.1

The Two Halves Need Different People#

The division is not bureaucratic tidiness. The halves fail differently.

Assessment answers what is true — an evidence exercise whose virtue is independence. An assessor with a stake in the release date finds fewer problems, not through dishonesty but because judgment bends under pressure. Authorization answers what we are willing to operate — a judgment about risk appetite and timing, belonging to someone senior enough to absorb being wrong.

RoleOwnsFails when
System ownerThe system, its risk, the remediation commitmentsTreats the assessment as an obstacle
AssessorThe evaluation, the evidence, the findingsIs not independent, or decides what is acceptable
AuthorizerThe decision, and the residual risk acceptedSigns without reading, or is too junior to refuse
OperatorsKeeping the controls working afterwardsAre never told what the authorization assumed

That last row is the one most often missed. An authorization rests on assumptions — that logs are reviewed, that access is recertified. If the people running the system never learn what those assumptions were, it starts decaying the moment it is signed.

What It Produces#

  1. A security assessment reportWhat was assessed, what was found, what risk remains
  2. A plan of action and milestonesWhat gets fixed, by whom, by when — and what risk is carried until then
  3. An authorization decisionWhether the system may operate, under what conditions, for how long

The report and the plan are inputs. The decision is the output, and the only one of the three that changes anything.

What SA&A Is Not#

Not an audit. An audit asks whether you conform to a standard and reports to a governance body. SA&A asks what risk one system carries and reports to a person who must decide about it.

Not a penetration test. A pen test is one narrow evidence source. An assessment covers controls it never touches — training records, contractual clauses, review cadences, backup restoration.

Not a one-time gate. An authorization describes a system as it was, on evidence as it was. Systems change and evidence ages. Authorization is maintained, not achieved.

Not a compliance checkbox. A control marked "met" with nothing behind it is worse than one marked "not met" — it converts an open risk into a closed one without changing anything.

Where CtrlFort Fits#

Everything above is sound on paper. What erodes it is scale — dozens of controls per system, several assessors, evidence scattered across inboxes and shared drives, and an authorizer asked to trust a summary they have no way to verify.

That gap is what CtrlFort Assess was built for, and the division of labour is the one set out in our assessment intelligence architecture: code evaluates, AI explains, humans decide.

  • Evidence stays attached to what it proves. In CtrlFort Assess, controls, findings, evidence, systems and risks are linked objects, so the walk from a conclusion back to the artifact behind it is a click rather than an archaeology project.
  • The evaluation is deterministic. The same inputs produce the same result for every assessor and every cycle — across ITSP.10.033, NIST SP 800-53 and the other frameworks a department is measured against. That is what makes results comparable between systems and defensible under challenge.
  • The explanation comes from the determination. CtrlFort AI drafts the narrative from the structured result, so what the report says can never quietly diverge from what was actually found.
  • The decision stays with a person. The platform assembles the evidence and the residual risk; accepting it remains the authorizer's signature, as it should.

The discipline does not need a platform to be sound. It needs one to stay consistent at scale — and consistency is what turns an assessment into something an authorizer can actually rely on.

Final Thoughts#

SA&A is often described as a compliance obligation. It is better understood as a decision-support function: its entire output is one accountable person, with evidence in front of them, deciding what the organization is willing to operate.

Judge a program on that basis. Not on how many controls were reviewed or how many findings were closed — on whether the decisions coming out of it are ones somebody could defend.

That is the standard we build CtrlFort against, and it is the thread running through the rest of this series: every step from scoping a system to maintaining its authorization exists to make one decision defensible.

Next: SA&A Terminology Explained

Frequently Asked Questions#

Is SA&A the same as certification and accreditation?#

In lineage, yes. C&A is the older vocabulary — certification for the technical evaluation, accreditation for the management decision. The terms were retired partly because "accreditation" suggested a standing qualification rather than a risk decision about one system at one time. You will still meet C&A in older documents.

Who signs the authorization?#

Someone senior enough to carry the consequence, and independent of delivery. Usually a business executive who owns the service rather than the head of IT security — the person accepting the risk should be the person it actually lands on. Security advises; it does not usually authorize.

Can we authorize a system with open findings?#

Yes, and this surprises people. Authorization is not a statement that everything is fixed — it is a statement that the remaining risk is understood and accepted. Open findings sit in the plan of action and milestones with owners and dates. An organization that will only authorize systems with zero findings will not authorize many systems.

How long does an SA&A take?#

Mostly it depends on how much control evidence already exists and how clearly the system's boundary is defined. With current documentation and controls inherited from an authorized platform, weeks. Where the boundary is disputed and evidence must be created from nothing, months — and most of that is not assessment work, it is discovering what was never written down.

References#

  1. ITSG-33 — IT security risk management: A lifecycle approach ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/it-security-risk-management-lifecycle-approach-itsg-33
  2. ITSG-33 Annex 2 — Information System Security Risk Management Activities ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-2-information-system-security-risk-management-activities-itsg-33
  3. NIST SP 800-37 Rev. 2 — Risk Management Framework for Information Systems and Organizations ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/37/r2/final
  4. ITSP.10.033 — Security and privacy controls and assurance activities catalogue ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033
  5. Policy on Government Security ↩Treasury Board of Canada Secretariat · https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=16578
On this page

On this page

  1. What SA&A Is
  2. Why It Exists
  3. The Two Halves Need Different People
  4. What It Produces
  5. What SA&A Is Not
  6. Where CtrlFort Fits
  7. Final Thoughts
  8. Frequently Asked Questions
  9. References

Zeeshan Mahmood

Security Assessment, Architecture & AI

Zeeshan is a security advisor and senior IT security risk analyst who works at the seam between assessment and design. He runs the full authorization lifecycle — security categorization, threat and risk assessment, control profile selection, and the evidence behind an authority to operate — and designs the solution, cloud and security architecture that has to survive it, from landing zones and network segmentation to Zero Trust and cross-domain solutions. His current focus includes AI security and the assessment of AI-enabled systems. He holds CISSP, CCSP, CISM, CKS and Azure Solutions Architect Expert, and leads assurance methodology at CtrlFort.

Run this framework against your own control library.

CtrlFort Assess maps cloud control profiles, ITSG-33 baselines and certification regimes to one shared evidence base — so a control you evidence once satisfies every obligation it maps to.

Book a demo → Explore the platform

Keep reading

Risk & Compliance01

From Assessment to Accountability: A Risk Register That Actually Works

Assessments identify risk; the register manages it — the ownership model that turns findings into decisions, and how CtrlFort runs it

·17 min Read →
Risk & Compliance02

How Dangerous, How Exposed, What Remains: A Working Model for Residual Risk

The three-formula risk model inside CtrlFort Assess — threat from likelihood and capability, vulnerability from prevention and response weakness, and the residual risk left at their intersection

·19 min Read →
AI & Governance03

How CtrlFort Uses AI to Deliver Repeatable, Explainable and Defensible Assessments

Code evaluates, AI explains, humans decide — inside the assessment intelligence architecture behind CtrlFort Assess

·11 min Read →