The Data Behind My ISC2 CC Exam Experience

6 days ago
11 min read

What made a data analyst take a second look at her own exam session — what turned out to be noise, and the one thing that didn't.

Update note:

This post reflects the data available at the time of publication. The Pearson VUE session event log was formally requested and, as of publication, has not been provided. If that changes, this post will be updated — but the investigation stands on its own without it.

Section 01

Setting the Scene: What Actually Happened

On June 20, 2026, I sat the ISC² Certified in Cybersecurity exam at a Pearson VUE testing center. I had been preparing for months, and not from a single source. I read the Mike Chapple study guide front to back, worked through his video series, completed ISC²'s own official training, and sat in on two ISC² webinars about the exam. I went through the Codecademy course, watched walkthrough videos on how to actually reason through the questions, ran daily practice through Pocket Prep, and kept a wrong-answers journal — because I spent more of my review time understanding why I missed something than chasing the next right answer. I tracked my domain performance week over week in a spreadsheet. I went in prepared.

The session ended at 90 questions.

No error message. No explanation at the terminal. The exam simply stopped, the screen cleared, and that was it. I had time remaining on the clock. Nothing in the experience itself signaled that anything had gone wrong — and yet, 90 questions is not within the documented range for this exam.

I'm a Senior Data Analyst. When something terminates outside its expected parameters, I don't assume it's fine. I go looking for data.

Session Facts — June 20, 2026

Questions answered	90 (below the documented minimum exam length)
Documented question range (CC)	100 – 125 questions
Time remaining at termination	Yes — clock had not expired
Error message displayed	None
Formal inquiry filed	Yes — ISC2 and Pearson VUE
Retake scheduled	August 15, 2026

Section 02

What the CAT Algorithm Is Supposed to Do

The ISC² CC uses Computer Adaptive Testing, or CAT. If you haven't encountered this format before, here's what it means in plain terms: the exam doesn't deliver a fixed set of questions in a fixed order. Instead, the algorithm selects each question based on your performance on the previous one. Answer correctly, and the next question gets harder. Answer incorrectly, and the difficulty adjusts down. The system is constantly recalculating where you sit relative to the passing standard.

Termination in a CAT exam is supposed to happen under one of three conditions: you reach the maximum question count (125 for the ISC² CC), the time limit expires, or the algorithm reaches statistical confidence that your ability is either clearly above or clearly below the passing threshold — in which case, continuing to deliver questions would not change the outcome.

There's one more wrinkle worth naming, because anyone who knows this exam will bring it up: a portion of the questions you see on a CAT exam are unscored pretest — "beta" — items. They're being trialed for future exams and don't count toward your result, and you have no way of knowing which ones they are while you're sitting there. This matters for reading a score report honestly. If some of the questions I saw in a given domain were unscored beta items, then what appeared on screen wouldn't map one-to-one onto the scored domains on my report. It's one ordinary explanation for why a practice pattern might scramble on exam day — and I'd rather raise it myself than pretend it isn't a factor.

Here's the key thing: beta items are counted within the questions you answer. They're part of the total, not additional to it. So they don't explain a session ending at 90. If anything, they make 90 stranger — the count already includes the padding that's supposed to be there.

That last condition is the one that matters here. Early termination at high confidence is a documented feature of CAT. If the algorithm determines with sufficient certainty that you have passed or failed, it stops. This is by design.

The documented finding

ISC²'s official Computerized Adaptive Testing (CAT) documentation states that candidates receive a minimum of 100 items on all CAT examinations. For the Certified in Cybersecurity (CC) exam, the total exam length ranges from 100 to 125 items. Of the first 100 items, 75 are operational (scored) questions and 25 are pretest (unscored) questions.

The same documentation explains that the Confidence Interval Rule can only be applied after the minimum exam length of 100 items has been completed. In other words, an exam cannot end through the confidence rule before a candidate has answered at least 100 questions. The remaining documented termination conditions are reaching the maximum exam length of 125 items or the expiration of the allotted testing time.

My examination session concluded after 90 questions, with time remaining on the exam clock. Based on ISC²'s published CAT rules, this outcome does not align with any of the documented exam termination conditions: the session did not reach the 100-item minimum required before the confidence rule may be applied, it did not reach the maximum length of 125 items, and it did not end because the allotted testing time expired.

This distinction matters. An early termination at 110 questions would be a routine outcome — past the 100-item minimum, the confidence rule can end the exam there. A termination at 90 falls before that minimum, so none of ISC²'s three documented rules account for it. The event log could provide additional information about why the session terminated when it did, but the gap between 90 and the documented 100-item floor stands on the published rules alone.

Section 03

What the Score Report Shows

The score report I received breaks performance down by domain rather than giving a raw score. Each domain is rated as Above Proficient, Near Proficient, or Below Proficient. Here is what it showed:

Domain Performance — ISC² CC Score Report

Domain 1 — Security Principles	Below Proficient
Domain 2 — Business Continuity, DR & IR	Below Proficient
Domain 3 — Access Controls	Below Proficient
Domain 4 — Network Security	Above Proficient
Domain 5 — Security Operations	Below Proficient

On its face, this is the score report of someone who did not pass. But there are details here that don't sit right when I look at them analytically — and I don't mean subjectively. I mean against my own recorded practice data.

I tracked domain-level performance across every practice test I took. The pattern was consistent for weeks: Domain 4 — Network Security — was my weakest area, scoring 80–90%. Every other domain — Security Principles, Business Continuity, Access Controls, Security Operations — sat at 100%. Domain 4 was the one I still didn't feel I had a firm grasp on. The others were locked in.

The score report inverted that pattern. Domain 4, my weakest in practice, came back Above Proficient — my only Above Proficient. The four domains I consistently scored highest in practice came back Below Proficient. Against a preparation pattern I'd tracked for weeks, that was a sharp enough deviation to make me look closer.

Practice vs. Reported — Domain Inversion

Domain 1 — Security Principles	Practice ~100% → Below Proficient
Domain 2 — Business Continuity, DR & IR	Practice ~100% → Below Proficient
Domain 3 — Access Controls	Practice ~100% → Below Proficient
Domain 4 — Network Security	Practice 80–90% → Above Proficient
Domain 5 — Security Operations	Practice ~100% → Below Proficient

I want to be careful here, because this is exactly the kind of pattern where it's tempting to overreach. Practice scores are not exam scores. A quiz bank is not the real question pool, unscored beta items muddy the domain mapping, and it's normal to underperform your practice numbers under pressure. All of that is real, and none of it should be waved away. What caught my attention wasn't a small dip — everyone dips a little on exam day — but a full reversal of a pattern I'd tracked for weeks. That was enough to make me stop and look, not enough on its own to conclude anything.

The inversion deviated far enough from my tracked practice baseline to warrant investigation. It was as if I'd opened my results and found the Mona Lisa where the domains should have been. It didn't sit right with me — that's what prompted me to post to Reddit and check ISC²'s documentation on CAT testing.

Analyst note

Looking at it from a data perspective, the inversion has an ordinary explanation — 75 scored items across 5 domains, compensatory scoring where strong domains offset weak ones, so few questions per domain that a rating can swing. That explained the inversion. What it didn't explain was the 90-question count.

Section 04

The Reddit Data Point

After the exam, I posted about my experience on Reddit in the r/isc2 community. While anecdotal rather than authoritative, the discussion provided an independent community data point worth documenting. I described the early termination at 90 questions, the time remaining on the clock, and the domain performance pattern. The post reached the #1 spot on the subreddit and drew significant engagement from other candidates and certified members.

What that response revealed was meaningful: the community largely agreed that 90 questions was anomalous. Experienced members who had sat the exam multiple times or who work in testing environments noted that early termination below 100 questions was not a standard CAT outcome they had encountered. Several respondents shared their own question counts — all at or above the 100-item minimum. And one candidate reported that the same thing had happened to them: a session that ended below the expected floor. One account isn't a pattern, but it's a second data point pointing at the same irregularity — and in analysis, the second occurrence of something you were told shouldn't happen is exactly the one you write down.

Community Signal — r/isc2

Post rank on r/isc2	#1
Community consensus on 90 questions	Anomalous — not a standard outcome
Other candidates' reported question counts	At or above the 100 minimum
Other reports of sub-100 termination	One candidate reported the same

Community data is not the same as official documentation. Reddit is anecdotal, and absence of evidence in a forum thread is not evidence of absence in the broader population. As a signal — a second data source that independently flags the same anomaly — it matters. In data analysis, when a second independent source points at the same thing the documentation already flagged, you note it and keep it in view — not as proof, but as one more reason the question was worth asking.

[ LOG ]

Pearson VUE Event Log — Requested, Not Provided

The event log for this session — question delivery timestamps, system flags, any logged errors — was formally requested from Pearson VUE. It is the one artifact that could definitively confirm or rule out a technical fault at question 90. As of publication, it has not been provided, and enough time has passed that I'm no longer counting on it arriving. The absence of the requested log means the investigation is limited to the available evidence. If additional documentation is ever provided, those findings can be revisited.

Section 05

The Security Analyst Lens

Here is where my background becomes directly relevant — not as a metaphor, but as a methodology.

In security operations, when a process terminates unexpectedly, you do not assume it completed normally. Unexpected termination is itself an event. It gets logged, reviewed, and investigated. The absence of an error message does not mean the absence of an error — it means the error either wasn't surfaced to the user or wasn't captured in a way that was visible at the terminal.

This is a foundational principle in anomaly detection: the thing that doesn't show up where it's supposed to is just as informative as the thing that does show up where it isn't supposed to. The inverted score distribution was the signal that made me investigate. What the investigation confirmed was the harder fact — ninety questions where the documented floor is one hundred, a gap in expected behavior that the exam's own published rules do not account for.

"Finding things that don't belong" is the through-line of this entire blog. I didn't expect to have to apply it to my own exam session.

A SOC analyst in this situation would follow a structured process. I followed the same one.

Step 1 — Identify

Recognized the session termination at 90 questions as outside documented parameters

Step 2 — Document

Captured all available data: question count, time remaining, score report, session details

Step 3 — Correlate

Compared score report against preparation data and identified the domain performance inversion

Step 4 — Escalate

Filed formal inquiry with ISC2 and Pearson VUE; requested the session event log

Step 5 — Await Evidence

Retake granted; event log requested but not provided; findings documented on the record

Step 6 — Continue Operations

Studying continued; retake scheduled for August 15; blog arc documented throughout

Following my exam, ISC² acknowledged my concerns regarding the testing session and provided a complimentary retake opportunity, which I appreciated and accepted. I do not present the complimentary retake as evidence that ISC² determined the examination was administered incorrectly or that any fault was established. ISC²'s published policy already allows candidates to retake the examination after the required waiting period if they do not pass. The complimentary retake and acknowledgment are presented here as factual events; my analysis of the session rests on ISC²'s published CAT documentation and the documented circumstances of my exam, not on the fact that a retake was offered.

Section 06

What's Still Unknown

I want to be precise about what I'm claiming and what I'm not.

I am not claiming definitively that a technical error caused my session to end early. I don't have the event log — it was requested and never provided. I don't have confirmation from ISC² or Pearson VUE about what happened at question 90. What I have is a set of data points that are inconsistent with a clean, standard session — and a request for answers that went unanswered.

What I am saying is narrower, and it rests on the two facts that held up under scrutiny: my session ended at 90 questions, below the documented 100-item minimum, with time still on the clock. The domain inversion that first caught my attention turned out to have an ordinary explanation, and the complimentary retake is consistent with standard policy — I've set both aside rather than count them as evidence. What remains is a question count that ISC²'s own published rules do not account for.

Honest analysis means acknowledging the limits of what you can conclude from incomplete data. The event log would have either clarified or deepened what I found here — but it was requested and never provided, and enough time has passed that I'm treating its absence as the answer I'm going to get. That absence is itself a data point. What I can do is document what I know, continue studying, and show up on August 15th with the same preparation and a clearer understanding of what that exam actually tests.

Section 07

Why This Matters Beyond My Situation

CAT-based certification exams are widely used. ISC², CompTIA, and several other major bodies deliver exams through adaptive testing platforms, and Pearson VUE is one of the largest proctoring providers in the world. Most candidates who sit these exams have no technical background to evaluate what happens during their session. They receive a pass or fail result, and they accept it.

I want to be clear: I am not suggesting that results are routinely wrong or that the system is broken. What I am saying is that test-takers have more options than many realize when a session feels anomalous.

You can request an inquiry. You can ask for the event log. You can document what you observed — the question count, the time remaining, anything in the testing environment that seemed off — and you can escalate it through official channels. These are not aggressive moves. They are reasonable responses to anomalous data, and they are options that many candidates don't know exist because no one tells them.

I chose to publish this because I believe documenting unusual technical events and being transparent about what is known and unknown is a part of developing the mindset cybersecurity requires. Security professionals don't ignore anomalies; they also don't jump to conclusions. They observe, gather evidence, question assumptions, acknowledge uncertainty, and document what they find.

Data literacy is a self-advocacy tool. That's not a metaphor specific to cybersecurity. It applies here, concretely, to anyone sitting a high-stakes exam and receiving a result that doesn't match what they observed during the session.

What Comes Next

The August 15 retake is scheduled. The inquiry was filed. The event log was requested — and never came. The investigation stands on the data I have.

Next up: an in-depth look at how I'm rebuilding my prep for round two — studying scenario-based questions differently, and treating the retake like the follow-up investigation it is.

The investigation continues.

Sources & References

Official Documentation

ISC² – Certified in Cybersecurity (CC) Exam Outline
ISC² – Computerized Adaptive Testing (CAT) Information

Additional Context

Reddit discussion in r/isc2 (my original post and community responses), referenced only as anecdotal community discussion and not as authoritative evidence.