u/Flat-Primary-255

On what do you focus when assessing the vendor?. Assume a generic saas vendor touching your data, network

View Poll

I love risk mgmt BUT how much value really brings? I worked for highly regulated and tech, for reference, and I feel risk mgmt is the mean to nothing. Trapped between the low hanging fruit of isolated and atomic issues, in general, with low impact vs glorified macro risk categories that are reading tea leaves. Is anybody proud pf any risk they managed or fully remediated (aka reduced) that you feel proud about?

I love risk mgmt BUT how much value really brings? I worked for highly regulated and tech, for reference, and I feel risk mgmt is the mean to nothing. Trapped between the low hanging fruit of isolated and atomic issues, in general, with low impact vs glorified macro risk categories that are reading tea leaves. Is anybody proud pf any risk they managed or fully remediated (aka reduced) that you feel proud about?

What is thebest security framework to use (or combination of 2 or more) to define a decent security program (with right altitude, meaning, control/req granularity, not too much not too vague)

IMO Iso27k1 + NistCSF

Okta says the average company runs 101 apps (Businesses at Work 2025, their own customer data). That number can only count apps actually plugged into Okta.

So how many are there really? Two published stats:

• 1Password: 30% of apps sit outside SSO
• Obsidian: more than 80% are unfederated

Do the maths on 101:

• 30% outside → ~144 apps total
• 80% outside → ~505 apps total

Same starting point, 3.5× apart. All three numbers are in circulation right now.

And yes, they're partly measuring different things — that's the interesting bit.

LayerX counts logins, not apps: 96% of email logins skip SSO, 83% ERP, 71% CRM. A few busy apps outside SSO gets you a huge login number and a small app number at the same time. So that stat isn't in conflict with anything — it's answering a different question, and nobody says which when they quote it.

But 1Password's 30% and Obsidian's 80% are both counting apps, and they still don't agree. 1Password surveyed 5,200 workers. Obsidian used its own telemetry. A survey asks people about apps they know about — shadow IT is the apps they don't. So 30% is a floor and 80% is nearer the ceiling.

Which makes the gap between them the most useful number here: a rough measure of how much of your estate nobody can see.

Fair warning on all of it, mine included: three of these four come from vendors counting their own customers — people who bought the tool because they already suspected a problem. None of them mentions that. Okta's 101 is OIN apps only. LayerX never states a sample size.

Anyone got an app-count number that isn't from someone selling the fix? I couldn't find one.

I was counting controls per family in 800-53 and hit a disagreement I couldn't resolve, so I went and counted from the OSCAL catalogue directly.

SC (System and Communications Protection):

• 47 active base controls
• 4 withdrawn
• 51 if you count the withdrawn ones

Nobody is wrong. One figure counts the controls that exist, the other counts the controls that have ever existed. Neither source says which it's doing.

It goes all the way up. The numbers you see everywhere — "324 base controls", "1,196 controls" — are the withdrawn-inclusive ones. Active counts are 300 and 1,014. There are 182 withdrawn controls sitting in the usual figures and I haven't yet found a source that mentions it.

Withdrawals aren't spread evenly, which is where it starts to bite:

• SA — 39 withdrawn (7 base, 32 enhancements)
• SC — 23
• SI — 17
• AC — 16
• IA — 15

So if you're computing "we cover X% of the SA family", your denominator moves by 39 controls depending on a convention nobody stated.

Where this leaks into real numbers:

• "We implement 400 of the 1,196 controls" — against which denominator?
• Framework overlap percentages. Published overlap between security frameworks ranges from 40% to 96% depending who you ask, and some of that spread is exactly this.
• Any coverage or maturity score with a control count underneath it.

Check it yourself, takes five minutes:

curl -sSL -o cat.json \
  https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json

import json
groups = json.load(open("cat.json"))["catalog"]["groups"]

def withdrawn(c):
    return any(p.get("name") == "status" and p.get("value") == "withdrawn"
               for p in c.get("props", []))

for g in groups:
    live = [c for c in g["controls"] if not withdrawn(c)]
    gone = [c for c in g["controls"] if withdrawn(c)]
    print(f'{g["id"].upper():<4} {len(live):>3} active  {len(gone):>2} withdrawn')

This is Rev 5.2.0, by the way. Counts also move between revisions, and almost nobody states that either.

I'm not accusing anyone of anything — it's a stated-rule problem. Three words in a footnote ("active controls only") and the number becomes checkable. Without it, two people quoting the same catalogue can differ by 4x and both be right, which is the least useful kind of argument there is.

Genuine question for the room: does your GRC tool count withdrawn controls in its denominators? I don't know, and I'd like to.

I spent a while on a question that looked like it should be simple: of the controls in our ISO-shaped set, how many can actually be evidenced automatically from the systems we already connect to — AWS, GitHub, Okta — and how many will always need a human to say so?

For 27 in-scope controls: 11 are connector-observable. 16 are not, and never will be.

The 11 are access configuration, branch protection, MFA enforcement — that class of thing. A machine reads current state and tells you whether it matches intent. The 16 are the Organizational 5.x controls: policies, roles and responsibilities, supplier governance, review cadences. There is no API that returns "management actually reviewed this." What surprised me wasn't the ratio. It was how clean the line is. It isn't "hard to automate" versus "easy to automate" — it's a category boundary. Configuration state is observable. Organizational intent isn't. Better tooling doesn't move a control across that line; it just renders the same guess more confidently.

Which leaves the part I don't have a good answer for. For those 16 the evidence is an attestation: someone says it happened, and a date gets recorded. That is the identical artifact whether the control is genuinely operating or whether somebody clicked through a reminder — and nothing downstream can tell the two apart. A dashboard showing 27/27 green is showing you 11 observations and 16 assertions in the same colour.

And mine couldn't tell either, which is what prompted this. I only know the 11/27 split because I sat down and counted by hand. Nothing in the normal workflow surfaced it — no screen anywhere told me "these two greens mean different things." That seems like the actual problem: not that the 16 are unobservable, which is just true, but that the difference is invisible at exactly the moment someone is deciding whether they're covered.

(Disclosure: I work on tooling in this space, so I'm not neutral. Nothing to click and nothing to sell — I genuinely don't have the answer to the below.)

So, for the controls no connector can ever see: what do you actually do? Is there a form of attestation you'd defend to an auditor as meaningfully different from a checkbox — or is periodic human sign-off simply the floor, and the honest move is to stop pretending tooling adds assurance there?

>