Smallbrook Public Information Workspace¶

Smallbrook sells annual subscriptions by public site and storage allowance, with a modest setup fee for page migration. Agency editors prepare informational pages and downloadable publications in a private workspace, then publish approved versions to public sites. It excludes sensitive submissions, transactions, and critical operational workloads from its intended use. Drafts, editor identities, and publication integrity still require protection even though published material is public.

A small virtual-machine fleet hosts the editor application, a publishing worker, and a relational database, with separate object storage for drafts and published files. A public delivery cache serves published copies; the administrative workspace uses agency identity federation and multifactor access. Multiple agencies share application and database infrastructure, with tenant identifiers enforced in application queries. Recovery copies sit outside the primary operating environment, but permissions and dependency mapping are less mature than the team’s restoration procedures.

This fictional example describes the offering as of 2026-12-16. Its FedRAMP ID EXAMPLE-SMALLBROOK-REV5-B is an example identifier, not a Marketplace entry. The implementation claims, evidence, dates, and confidence estimates are invented; no FedRAMP approval or staff review is claimed.

All examples · JSON · CSV

Framework: Rev5; Class: B; format: 0.2.0; rules: 2026.11.02.01.

Migration situation¶

Migration remains substantially incomplete, despite weekly machine detection and working recovery procedures. The team must repair detection breadth, contextual evaluation, response history, and reporting completeness with limited engineering and adviser capacity. Most planned work falls in the first half of 2027, selected recommendation improvements extend into September, and two areas still lack credible completion dates.

CAP targets describe proposed work and do not establish approval to delay implementation. Plans extending beyond March 7, 2027 require the applicable approval and red-team arrangements described in deadlines; none is claimed in this example.

The September targets cover false-positive review consistency, overview reporting, and historical JSON retrieval. They reflect Smallbrook’s capacity and sequencing, not a general ranking of rule importance.

Response summary¶

Rule responses¶

VDR-CSO-DET: Vulnerability Detection¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

We manually run detection across the machine inventory each week and review service alarms, supplier notices, and reports sent to our support address. Reviews of publishing procedures, access decisions, and security documentation are irregular, and some resources have no recent evidence of complete detection. The operations log therefore captures technical findings more reliably than weaknesses in the processes used to run the service.

Customer risk

An incorrect procedure or unreviewed permission change may remain unnoticed even when weekly machine scans succeed. Agencies could rely on a protection that is documented but no longer operating as intended.

Provider compensation

The engineering lead reviews changes associated with active findings and asks the adviser to check high-consequence uncertainties. The team retains the coverage gaps in its report instead of treating the weekly scan as complete assurance.

Agency compensation

Agencies can limit the service to its documented public-information use and report behavior that differs from the service description. They can keep sensitive submissions and critical operational workflows outside the offering while detection coverage remains incomplete.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The operations team is building a resource-and-source register and has started checking missing procedure reviews. Complete coverage depends on the March evaluation and non-machine review work.

Target completion date

2027-03-31

Corrective actions

The security coordinator will assign detection methods and owners to machine, process, document, and supplier-related resources. Completion requires a reconciled coverage cycle, intake for non-scanner findings, and an explicit exception record when evidence is missing.

Confidence in target date (%)

70

VDR-CSO-RES: Vulnerability Response¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

The operations log records findings, assigned engineers, and repair notes, but evaluation and exploitation-review evidence are inconsistent. A weekly meeting prioritizes the backlog, with urgent service issues handled by the on-call engineer between meetings. Older entries sometimes show that a change was deployed without establishing its effect on exposure or whether the vulnerable condition was removed.

Customer risk

A repair note without evaluation or verification can leave agency exposure unresolved while the backlog appears to shrink. Missing ownership can also delay treatment when the primary operator is unavailable.

Provider compensation

The weekly meeting now names an engineer for each active item and checks recent repair notes for missing evidence. Urgent indications of compromise go to the on-call engineer without waiting for that meeting.

Agency compensation

Agencies can request the evidence supporting closure of a finding relevant to their site. They can maintain alternate publishing arrangements while the remaining exposure and treatment status are uncertain.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The team has begun assigning owners and separating repair notes from verified outcomes. Older findings still lack complete evaluations and treatment history.

Target completion date

2027-03-31

Corrective actions

The engineering lead will require each finding to retain its detection, evaluation, exploitation review, treatment, and reporting history. A review of the open backlog and recent closures will confirm ownership, evidence of actual reductions, and a traceable final disposition.

Confidence in target date (%)

70

VDR-CSO-FAV: Failures Are Vulnerabilities¶

Rule reference · Force for this profile: MUST

Implementation status: Not Implemented

Implementation explanation

Failed detection jobs and report corrections have been handled as maintenance tickets without creating corresponding vulnerability records. The team normally restores the job but does not consistently investigate what was missed during the failure. We have begun designing the new intake process, but it is not yet operating as a routine control.

Customer risk

A restored job can conceal a period in which findings or report changes were missed. Agencies may be unaware that the information they received covers only part of the reporting interval.

Provider compensation

Operators retain failed-job logs and repeat missed machine detection within the weekly interval. The engineering lead is reviewing recent maintenance tickets for possible security coverage gaps, although a routine vulnerability intake process is still absent.

Agency compensation

Agencies can ask whether a reported outage or delayed report affected detection coverage. They can request the corrected reporting interval before relying on the report for a risk review.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The new failure-intake procedure is being drafted from recent maintenance tickets. It has not yet been exercised or adopted by both operations generalists.

Target completion date

2027-01-31

Corrective actions

The security coordinator will turn failed detection and reporting activity into owned vulnerability records linked to the operational ticket. A missed-job exercise will verify coverage-gap investigation, repeat detection where needed, and inclusion of the failure and repair in the next report.

Confidence in target date (%)

90

VDR-CSO-DFR: Design For Resilience¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

The publishing worker, editor application, and public delivery path have separate roles, and recovery copies are held outside the primary environment. Several service identities still have broader storage permissions than their functions need, and shared application components can affect multiple agency sites. Restoration is tested, but the design does not yet make tenant isolation and response evidence as dependable as the backup process.

Customer risk

Broad service permissions could allow compromise of one processing component to affect drafts or publications for several agencies. Successful restoration would not reverse information already disclosed.

Provider compensation

The team restricts interactive administration and separates recovery-copy access from normal runtime accounts. Engineers can suspend a publishing worker while examining suspicious activity, accepting a publication delay to limit further access.

Agency compensation

Agencies can keep sensitive drafts in an independently controlled system until publication is necessary. They can retain authoritative copies and verify unexpected publication changes through an alternate channel.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

Permission reduction and tenant-boundary work is scheduled after the initial evaluation and reporting repairs. The engineering lead has reserved capacity, but dependent application changes have not started.

Target completion date

2027-06-30

Corrective actions

Engineers will separate publishing, draft access, and administrative permissions and test cross-tenant denial at the application and storage boundaries. Acceptance requires recorded authorization tests, retained response evidence, and a recovery exercise showing that the narrower permissions still support restoration.

Confidence in target date (%)

60

VDR-CSO-ADT: Automate Detection¶

Rule reference · Force for this profile: SHOULD

Implementation status: Not Implemented

Implementation explanation

Operators start scans, collect results, and update the operations log by hand. Service alarms are automated, but there is no automated vulnerability intake, evaluation queue, response tracking, or reporting reconciliation. The team has not selected an affordable approach that it can operate without adding unowned integrations.

Customer risk

Manual copying can lose a finding or delay an update when the small team is handling an outage. The absence of an automatic queue also makes unresolved evaluation work harder to see.

Provider compensation

Both operations generalists attend the weekly backlog review and compare scan output with the shared log. The engineering lead checks urgent items during on-call handover so they do not depend on one person's notes.

Agency compensation

Agencies can request a dated status update for findings that affect their publishing work. They can escalate a missing or contradictory update through the named engineering contact.

Corrective action plan¶

CAP status

Pending Plan

Reason for CAP status

The team has not selected or funded an approach for automated vulnerability intake and response tracking. The engineering lead will compare coverage and operating cost by January 31 before making a completion commitment.

VDR-CSO-DAC: Detect After Changes¶

Rule reference · Force for this profile: SHOULD

Implementation status: Not Implemented

Implementation explanation

Engineers use a release checklist, but new and materially changed resources do not automatically initiate vulnerability detection. A changed publishing permission or dependency may therefore wait for the next manually initiated weekly run. The checklist includes a manual review, although evidence of those checks is not consistently retained.

Customer risk

A new dependency or permission change may expose draft or published content before the next weekly detection run. Missing release evidence makes it difficult to determine what was checked at activation.

Provider compensation

The release engineer asks a second engineer to review material changes before deployment. A suspected release-related weakness can be contained by reverting the change or disabling the affected publishing function while it is evaluated.

Agency compensation

Agencies can delay using a materially changed feature until its detection results are available. They can compare published content with retained copies after a release that affects their publishing path.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

Automatic change-triggered detection is scheduled after the machine-validation work. The release checklist remains manual while the team identifies representative tests for each deployment type.

Target completion date

2027-05-31

Corrective actions

The release owner will trigger detection from approved change records and retain the result against the deployed configuration. Completion requires tests for a new machine, a changed publishing permission, and a failed check that creates a tracked finding before unrestricted use.

Confidence in target date (%)

70

VDR-CSO-MSP: Maintain Security¶

Rule reference · Force for this profile: SHOULD NOT

Implementation status: Fully Implemented

Implementation explanation

Our assessment account uses the existing restricted management path and does not require public administrative access. Operators keep authentication, access restrictions, and logging enabled while running detection. If a check needs unsafe permissions or would disrupt publishing, the team uses an isolated copy and records the production coverage limitation for follow-up.

VDR-CSO-AKE: Avoid KEVs¶

Rule reference · Force for this profile: SHOULD NOT

Implementation status: Partially Implemented

Implementation explanation

Engineers check the known-exploited catalog when preparing major releases, but emergency rebuilds and added utility machines do not consistently have a recorded pre-activation check. The current checklist does not tie the decision to an exact component inventory. We therefore cannot show that every newly activated machine was free of known-exploited vulnerabilities at activation.

Customer risk

A utility machine or emergency rebuild could activate with a known-exploited component. That exposure may persist until the weekly review identifies the inventory match.

Provider compensation

The engineering lead manually checks catalog entries implicated by supplier notices before approving urgent rebuilds. Uncertain components can be kept inactive while the installed version is confirmed.

Agency compensation

Agencies can request confirmation of exposure when a known-exploited advisory affects the service's reported functions. They can suspend optional uploads or publishing activity while the provider determines whether the deployed component is affected.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The release checklist is being updated to cover emergency rebuilds and utility machines. Exact component inventories are still being added to the release records.

Target completion date

2027-02-28

Corrective actions

The engineering lead will require a current known-exploited catalog check against the exact component inventory before every new machine is activated. Acceptance requires a recorded second-person check and a demonstrated block on an affected release until the component is removed or replaced.

Confidence in target date (%)

85

VDR-CSO-SIR: Sampling¶

Rule reference · Force for this profile: MAY

Implementation status: Not Applicable

Implementation explanation

We run machine detection against the full small inventory and do not use representative sampling. The editor, database, and publishing functions differ enough that maintaining sample equivalence would add work without reducing effort materially. Each machine retains its own result in the operations folder.

Corrective action plan¶

CAP status

Not Applicable

Reason for CAP status

The team has chosen full-population machine detection and does not use sampling. No sampling corrective action is needed because each machine receives its own assessment.

VDR-TFR-NMV: Non-Machine Verification and Validation¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

Some publishing and recovery procedures have been exercised recently, but supplier handoffs, access-review instructions, and security descriptions lack complete verification and validation within three months. The current document list does not reliably identify an owner or next review date for every resource. A successful restore exercise therefore supports only that procedure and cannot establish coverage of the remaining non-machine resources.

Customer risk

Outdated access or supplier instructions can lead staff to follow a procedure that no longer provides the intended protection. Agencies may receive assurances based on documents that have not been compared with current operation.

Provider compensation

The adviser prioritizes procedures implicated by active findings and upcoming operational changes. Recent walkthrough records are retained so those reviewed procedures have a traceable basis even while overall coverage remains incomplete.

Agency compensation

Agencies can confirm current responsibilities and escalation contacts before relying on a documented handoff. They can raise inconsistencies between published instructions and actual support responses for investigation.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The document inventory is being reconciled with current operations and assigned to owners. Several resources still need a first complete verification and validation review.

Target completion date

2027-03-31

Corrective actions

Owners will compare each non-machine resource with observed operation and retain the evidence and resulting findings. The coordinator will establish a recurring schedule within three months and check that missed reviews are escalated rather than silently rolled forward.

Confidence in target date (%)

80

VDR-TFR-PDD: Persistent Drift Detection¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

Weekly machine checks provide recurring visibility into the deployed hosts, but frequently edited permissions procedures and publishing instructions are reviewed less than monthly. The team has not classified every information resource by its likelihood of drifting. This leaves gaps against the Class B monthly detection recommendation outside the machine scan coverage.

Customer risk

Changes to publishing or access instructions can introduce weaknesses that remain unnoticed beyond the monthly interval. Machine scan results do not show whether staff are following those instructions correctly.

Provider compensation

The engineering lead reviews procedure changes associated with releases and incidents. The operations team keeps a list of known review gaps for discussion with the adviser.

Agency compensation

Agencies can validate their own editor permissions and publication approvals after a process change. They can report unexpected access or publishing behavior instead of relying solely on the next provider review.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

The team plans to classify drift-prone resources after completing the initial inventory review. Monthly procedure detection has not yet been scheduled across that inventory.

Target completion date

2027-04-30

Corrective actions

The coordinator will classify resources by change behavior and assign detection at least monthly for those likely to drift. Completion requires a full recorded cycle, reconciliation with material changes, and a route for newly introduced resources to enter the schedule.

Confidence in target date (%)

75

VDR-TFR-PCD: Persistently Complete Detection¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

Stable machines are included in the weekly detection run, while some infrequently changed supplier and security documents have gone more than six months without a complete review. We have treated those documents as unchanged without checking whether the service still operates as they describe. Their detection coverage therefore remains incomplete even though machine results are current.

Customer risk

An old supplier responsibility or security description can be wrong for months without a detection review. Agencies may misunderstand which protections the offering actually provides.

Provider compensation

The team checks documents used in current investigations and marks unverified descriptions for review. Owners have begun reconciling the document list with the services and suppliers still in use.

Agency compensation

Agencies can request the last reviewed date of a description relevant to their use. They can avoid treating an unverified description as sufficient evidence for a consequential risk decision.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

Owners are checking the stable-resource list while recovering overdue document reviews. The first complete pass has not yet covered every supplier and security resource.

Target completion date

2027-03-31

Corrective actions

The team will assess all remaining stable resources and record the evidence supporting their classification. A recurring schedule will keep detection within six months, while non-machine verification and validation continues on its separate three-month schedule.

Confidence in target date (%)

80

VDR-TFR-PVR: Mitigation and Remediation Expectations¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

The team records urgent repair dates but has not consistently translated evaluated impact, reachability, and exploitability into the Class B reduction matrix. Supplier-dependent publishing components also lack dependable intermediate reduction plans. Some evaluation evidence is still incomplete, so we cannot demonstrate that reductions are achieved within the applicable intervals or support a credible date for complete implementation.

Customer risk

Weaknesses may retain their agency impact longer than the Class B reduction expectations. Incomplete evaluations can also lead the team to prioritize the wrong reduction first.

Provider compensation

The engineering lead reviews urgent known exposure with the adviser and considers disabling the affected feature when repair is uncertain. Interim actions remain described as provisional until their effect has been evaluated.

Agency compensation

Agencies can reduce use of an affected upload or publishing path while reduction evidence is incomplete. They can consider the remaining uncertainty in their own risk decisions rather than relying on a proposed repair date.

Corrective action plan¶

CAP status

Pending Plan

Reason for CAP status

Incomplete evaluations and uncertain supplier options prevent a defensible completion target for the reduction process. The engineering lead and adviser will review alternate treatment options and planning dependencies on January 31.

VDR-TFR-RMN: Remaining Vulnerabilities¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

Engineers repair residual weaknesses when they overlap planned maintenance, but the backlog has no dependable review for items outside that work. Older low-priority entries can remain unchanged through several release cycles. The team has not consistently recorded whether those findings were deliberately deferred, accepted, or simply overlooked.

Customer risk

Deferred weaknesses can accumulate until a later change makes one exploitable or more damaging. An agency may see the same open issue without a clear reason for continued delay.

Provider compensation

The weekly meeting checks older findings associated with upcoming releases and records a named owner. Newly relevant threat information can move an item into urgent work even if its earlier priority was low.

Agency compensation

Agencies can ask for a current rationale when a reported finding remains unchanged across several reports. They can limit use of the affected function if the residual exposure is no longer acceptable for their situation.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

A recurring residual-finding review is scheduled after the initial evaluation backlog is repaired. The engineering lead has not yet assigned maintenance capacity to all remaining items.

Target completion date

2027-05-31

Corrective actions

The maintenance owner will review residual findings regularly, assign treatment or a documented deferral, and reconsider them when threats or service use change. Completion requires a reconciled backlog showing an accountable owner and a supported disposition for each remaining weakness.

Confidence in target date (%)

75

VDR-TFR-KEV: Remediate KEVs¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

We check supplier notices and the known-exploited catalog during the weekly review, but catalog due dates are not consistently recorded against deployed components. A temporary restriction has sometimes been treated as sufficient progress while the underlying component remained affected. We need a reliable inventory match and remediation deadline process that stays open until removal of the vulnerable condition is verified.

Customer risk

A known-exploited component may remain installed past its catalog remediation date. Filtering or restricted use can leave a viable exploitation path that the team has not established or removed.

Provider compensation

Engineers give known-exploited matches priority in the weekly review and investigate urgent supplier notices on receipt. The team can withdraw an affected optional function while it determines how to replace or remove the component.

Agency compensation

Agencies can request the applicable catalog deadline and the current remediation evidence for a relevant finding. They can avoid the affected function while the provider cannot demonstrate removal of the vulnerable condition.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The team is matching deployed components to catalog entries and recovering missing due dates. A reliable verification step for removal of the affected condition is still being introduced.

Target completion date

2027-02-28

Corrective actions

The security coordinator will maintain current catalog matches and remediation dates for deployed components, with escalation before a deadline is missed. Engineers will verify removal or replacement of the vulnerable condition and keep interim mitigation separate from remediation completion.

Confidence in target date (%)

85

VDR-TFR-PSD: Persistent Sample Detection¶

Rule reference · Force for this profile: SHOULD

Implementation status: Fully Implemented

Implementation explanation

Operators perform detection on every machine at least once every seven days and retain the results against the current inventory. A failed run is repeated within the seven-day interval, and the other operations generalist covers absence of the primary operator. This meets the Class B machine-detection cadence, while broader process coverage and full configuration validation remain separate gaps.

VDR-TFR-MVX: Persistent Machine Verification and Validation for 20x¶

Rule reference · Force for this profile: Not applicable to this framework

Implementation status: Not Applicable

Implementation explanation

Smallbrook Public Information Workspace follows the Rev5 Class B profile. The 20x-specific machine-verification rule is not applicable, and our gaps against the corresponding Rev5 recommendation are reported under VDR-TFR-MVF.

Corrective action plan¶

CAP status

Not Applicable

Reason for CAP status

The 20x machine-verification rule is outside the Rev5 profile of this offering. The applicable monthly recommendation and its corrective work are recorded under VDR-TFR-MVF.

VDR-TFR-MVF: Persistent Machine Verification and Validation for Rev5¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

Weekly scans identify machine weaknesses, but they do not fully verify approved configuration or validate that every protective function operates as intended. Storage permissions, logging failure behavior, and tenant-boundary checks lack a complete monthly evidence set. The current coverage is therefore short of the Rev5 Class B monthly verification and validation recommendation.

Customer risk

A machine can pass a vulnerability scan while its permissions or logging behave differently from the approved design. Agencies may therefore have less isolation or investigation evidence than the service description suggests.

Provider compensation

Engineers manually check sensitive storage permissions after material changes and retain available audit records. The adviser prioritizes tenant-boundary and logging checks when reviewing the current backlog.

Agency compensation

Agencies can review their editor accounts and keep independent records of important publication changes. They can request specific configuration-validation evidence when the protection is material to their use.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

Monthly configuration verification and behavior tests are planned after the inventory and evaluation repairs. The adviser is helping define checks that the small team can repeat and retain.

Target completion date

2027-04-30

Corrective actions

Operations will compare each machine with its approved configuration and validate tenant access, protective settings, and logging behavior. A complete monthly cycle must account for every machine and create findings for failed or unperformed checks.

Confidence in target date (%)

75

VER-EVA-ELX: Evaluate Exploitability¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

Initial reviews consider the affected package and supplier severity, but often lack evidence about enabled code paths, required privileges, and actual protections. The publishing worker's processing of uploaded material has not been consistently evaluated in that context. A weekly review entry therefore does not always establish a supported likely-exploitability decision.

Customer risk

A finding may be dismissed or assigned low urgency before the deployed exploitation conditions are understood. That can delay protection of drafts or publication integrity.

Provider compensation

Engineers retain uncertain findings as open and request adviser input for privileged or shared components. Affected optional functionality can be restricted while the missing evidence is investigated.

Agency compensation

Agencies can describe how they use the affected function and identify any sensitive workflow dependencies. They can pause that use when the provider cannot yet support its exploitability assessment.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

Engineers have started adding deployed-function and permission evidence to new evaluations. Older findings still need review, and adviser capacity limits progress on complex cases.

Target completion date

2027-03-31

Corrective actions

The evaluation owner will document required conditions, reachable functionality, and current protections for each detected weakness. Completion requires review of the open backlog and a repeatable intake process that records a supported likely-exploitability determination.

Confidence in target date (%)

75

VER-EVA-EIR: Evaluate Internet-Reachability¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

The team can identify public endpoints but has sometimes treated private hosts as unreachable without tracing the content they process. Uploaded publications and queued publishing jobs can carry internet-originated input into the private worker. Those indirect paths and the relevant permissions are not yet documented consistently enough to support every reachability decision.

Customer risk

A private publishing worker may process attacker-controlled content despite having no public administrative endpoint. An incorrect unreachable classification could delay treatment or understate agency exposure.

Provider compensation

The team checks the upload and publication path for findings already under investigation. Unresolved indirect paths remain an explicit uncertainty instead of being treated as proof of isolation.

Agency compensation

Agencies can limit uploaded material to approved sources while an affected processing path is evaluated. They can use an alternate publication method if the remaining reachability uncertainty is material.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The upload-to-publication data flow is being mapped and used in current investigations. Integration and administrative input paths still need consistent coverage.

Target completion date

2027-03-31

Corrective actions

Engineers will trace direct and indirect internet-originated input to each affected function and retain the relevant permissions and routing evidence. Reviewers will revisit open findings previously classified from network location alone and confirm that changed paths trigger reassessment.

Confidence in target date (%)

70

VER-EVA-EPA: Estimate Potential Agency Impact¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

Early evaluations emphasize restoration time and public-site availability, with less attention to draft disclosure, unauthorized publication, and shared-service effects across agencies. Some N-ratings were assigned from generic severity without a clear explanation of the likely customer effect. The adviser is helping the team revisit those ratings using the actual publishing workflow and data boundaries.

Customer risk

An availability-focused rating can understate draft disclosure, unauthorized content changes, or effects across multiple agency sites. Agencies may then receive an urgency estimate that does not reflect their actual use.

Provider compensation

The adviser reviews findings involving shared storage, administrative permissions, or publication authority. Engineers seek agency context before lowering an impact rating whose consequences remain uncertain.

Agency compensation

Agencies can explain the consequences of incorrect publication or draft disclosure for their site. They can request reevaluation when the provider's stated assumptions omit those consequences.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The adviser is reviewing shared-service and publication-integrity cases with the engineering lead. Existing ratings still include unsupported availability-only judgments.

Target completion date

2027-02-28

Corrective actions

The team will evaluate likely confidentiality, integrity, and availability effects on agency use and assign the corresponding N-rating with a recorded rationale. Acceptance requires review of open findings for multi-agency consequences and incorporation of relevant customer context.

Confidence in target date (%)

85

VER-EVA-AIA: Assume It's Automatable¶

Rule reference · Force for this profile: MUST

Implementation status: Fully Implemented

Implementation explanation

Our evaluation instructions require reviewers to assume exploitation can be automated. The team does not claim exceptions based on a lack of observed attacks or the apparent complexity of an exploit. Any future exception would need specific technical evidence and adviser review before the assumption could change.

VER-EVA-GRV: Group Vulnerabilities¶

Rule reference · Force for this profile: SHOULD

Implementation status: Not Implemented

Implementation explanation

We keep individual finding records because the small inventory contains different functions and repair paths. The engineering lead has documented the decision not to consolidate response activity into groups at this stage. Related entries can be cross-referenced during the weekly meeting, while each affected resource retains its own evidence and status.

Customer risk

Individual records can cause duplicate work and inconsistent repair decisions for related resources. The small team may overlook that one deployment change could address several entries.

Provider compensation

The weekly review cross-references findings that involve the same component or release. Each affected machine still needs its own verification before the corresponding entry is closed.

Agency compensation

Agencies can ask whether repeated findings share a cause or planned repair. They can check that a claimed common repair actually includes the function used by their site.

Corrective action plan¶

CAP status

Not Applicable

Reason for CAP status

The engineering lead has documented a justified departure from consolidated response groups for the small, varied inventory. Individual tracking remains the chosen approach, with cross-references used to manage related work.

VER-EVA-EFP: Evaluate False Positives¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

Engineers investigate suspected false positives when a finding blocks a release, but routine findings do not receive the same consistent evidence review. Some notes state that a warning was dismissed without explaining the deployed condition or the basis for that conclusion. We have stopped treating those old dismissals as established facts while the evaluation backlog is repaired.

Customer risk

An unsupported dismissal can hide a real weakness, while unresolved noise can consume the team's limited review time. Both can delay attention to findings that affect agency publishing.

Provider compensation

Older unsupported dismissals are returned to open review when encountered, and release-blocking disputes receive engineering evidence checks. The team does not apply a blanket suppression across versions or configurations.

Agency compensation

Agencies can request the basis for a dismissal that affects their reported exposure. They can treat an unresolved conclusion as uncertainty in their own risk review rather than assuming the weakness is absent.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

A consistent false-positive review process is scheduled for September after mandatory evaluation repairs. Until then, unsupported dismissals remain subject to open review and are not treated as verified absence of a weakness.

Target completion date

2027-09-15

Corrective actions

The evaluation owner will require evidence distinguishing an absent vulnerability from constrained exploitation and record the configuration to which a conclusion applies. Completion requires review of existing dismissals and tests showing that changed components or exposure invalidate stale suppressions.

Confidence in target date (%)

60

VER-EVA-EFA: Evaluation Factors¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

The working checklist covers component severity and service availability, with uneven attention to privileges and input paths. It does not consistently examine detectability, prevalence, nearby vulnerabilities, or known threats in the offering's context. The mandatory evaluation repairs are being addressed first, followed by a fuller worksheet for these recommended factors.

Customer risk

A narrow worksheet can miss how a weakness combines with broad permissions or another unresolved finding. The resulting treatment priority may not reflect the likely customer consequence.

Provider compensation

The adviser reviews shared and privileged components first and discusses related open findings with the engineers. Those targeted reviews reduce some uncertainty while full factor coverage remains incomplete.

Agency compensation

Agencies can identify unusual dependencies or consequences that a routine publishing use case would not reveal. They can request an updated assessment when that information changes the context.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

The broader factor worksheet is planned after the mandatory contextual determinations are established. The adviser has not yet reviewed its use across the open backlog.

Target completion date

2027-06-30

Corrective actions

The security coordinator will add every recommended evaluation factor, including interactions with nearby weaknesses and known threats. Reviewers will revisit open findings and record whether the added context changes impact, priority, or treatment.

Confidence in target date (%)

65

VER-RPT-PER: Persistent Reporting¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

Monthly reports summarize selected findings and repairs, but they do not account for all detection and response activity since the preceding report. Successful checks, failed jobs, and changes recorded only in engineering notes can be omitted. The operations generalist has started reconciling the log and those notes, but complete activity reporting is not yet established.

Customer risk

An omitted check or response event can make the report appear more complete or current than the underlying work supports. Agencies may miss a coverage failure or an important change in exposure.

Provider compensation

The operations generalist compares recent engineering notes with the log before publication and flags known omissions. Corrected reports are dated so recipients can identify which reporting interval was repaired.

Agency compensation

Agencies can ask whether the report has been reconciled with all activity sources. They can retain revisions and request clarification when a finding disappears without an explained disposition.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The operations generalist has started reconciling engineering notes and scan results with the reporting log. Complete source accounting and correction handling are not yet routine.

Target completion date

2027-02-28

Corrective actions

The reporting owner will account for all detection and response activity since the prior report, including verification results and process failures. Completion requires a reconciled reporting interval, delivery to all necessary parties, and a tested correction process that preserves the interval and revision history.

Confidence in target date (%)

85

VER-RPT-VDT: Vulnerability Details¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

Our report contains finding identifiers, short descriptions, and intended repair dates, but several required details are missing or inconsistent. Detection sources, completed evaluation times, evaluated impact reductions, and overdue explanations are particularly weak in older entries. Some necessary context does not yet exist because the underlying evaluation is unfinished, so export changes alone will not resolve the gap.

Customer risk

Missing evaluation times and reduction history make it difficult to judge exposure duration and treatment progress. An unsupported target can look more certain than the available evidence warrants.

Provider compensation

The team labels unknown values and requests source evidence from the responsible engineer. It avoids inventing historical dates when the retained records cannot support them.

Agency compensation

Agencies can request the missing detail for findings relevant to their use and distinguish estimates from verified reductions. They can retain uncertainty in their risk assessment until the underlying evaluation is complete.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The report layout is being expanded while engineers recover supporting history and complete missing evaluations. Some required values cannot be populated responsibly until that work finishes.

Target completion date

2027-03-31

Corrective actions

The reporting owner will map every applicable detail field to the operations record and retain evidence for dates and impact reductions. Acceptance requires a complete export reconciled with the source records, explicit handling of overdue findings, and no invented historical values.

Confidence in target date (%)

75

VER-RPT-AVI: Accepted Vulnerability Info¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

Long-running findings are listed as accepted in some reports without a complete acceptance explanation or current contextual evaluation. Original detection and evaluation times are not consistently carried into that view. Agencies therefore do not always receive the information needed to understand the continuing exposure and decide how to use the publishing service.

Customer risk

An incomplete accepted-finding record can hide why exposure persists and what protective action remains possible. Agencies may mistake the provider's acceptance for a conclusion that no further decision is needed.

Provider compensation

The engineering lead reviews accepted entries during the weekly meeting and identifies missing rationale. The adviser prioritizes records involving shared components or publication authority for contextual review.

Agency compensation

Agencies can request an explicit acceptance explanation and current exposure assessment. They can make their own decision about continued use and apply practical restrictions where the record supports them.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

The accepted-finding review is planned alongside the report-field repair. The team first needs reliable evaluation times and acceptance categorization for those records.

Target completion date

2027-03-31

Corrective actions

The engineering lead will complete the current context of each accepted record, required dates, acceptance explanation, and useful agency actions. The reporting owner will check that changes to accepted findings remain visible and that acceptance is not presented as an agency decision.

Confidence in target date (%)

80

VER-RPT-NID: Responsible Disclosure¶

Rule reference · Force for this profile: MUST NOT

Implementation status: Fully Implemented

Implementation explanation

Vulnerability details are shared through a restricted customer area with named agency contacts and other necessary parties. The engineering lead reviews messages for information that could facilitate exploitation and provides available customer-impact context and practical actions without publishing exploit instructions. The report-field and evaluation gaps remain disclosed separately, rather than concealing uncertainty or treating restricted access as proof of complete reporting.

VER-RPT-HLO: High-Level Overviews¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

The opening report summary concentrates on uptime, backups, and the number of repaired machine findings. It does not consistently describe procedure reviews, supplier notices, or the investigations that remain incomplete. Readers cannot obtain a balanced overview of all detection and response activity from that summary today.

Customer risk

An uptime-centered summary can obscure unresolved security work affecting integrity or confidentiality. Agency reviewers may overlook a reporting or evaluation gap if they read only that summary.

Provider compensation

The report includes a visible list of known migration gaps and links to available finding detail. The engineering contact answers questions about omitted activity categories using the underlying records.

Agency compensation

Agencies can read the stated gaps alongside the availability summary. They can request a period-specific account of detection and response work before drawing conclusions from repair counts.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

The overview rewrite is scheduled after mandatory reporting content is repaired. The team has reserved a September review but has not yet designed a complete source-category summary.

Target completion date

2027-09-01

Corrective actions

The reporting owner will summarize every activity source and explain material changes, coverage gaps, and unresolved work for the period. Acceptance requires reconciliation with the detailed activity so uptime and repair counts cannot obscure missing evaluation or process work.

Confidence in target date (%)

70

VER-RPT-RPD: Responsible Public Disclosure¶

Rule reference · Force for this profile: MAY

Implementation status: Not Applicable

Implementation explanation

We do not currently exercise the option to publish vulnerability details publicly. Necessary-party communications use the restricted reporting channel, with additional coordination when a supplier or agency needs technical information. Any future public disclosure would require a separate review of whether the proposed information is likely to enable exploitation.

Corrective action plan¶

CAP status

Not Applicable

Reason for CAP status

Smallbrook does not exercise optional public vulnerability disclosure. Necessary-party reporting and any independently required communications remain in scope through their existing channels.

VER-TFR-MHR: Monthly Activity Report¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

We deliver a human-readable report each month using the same headings and customer distribution list. Its activity content is incomplete because source reconciliation and several required detail fields remain unfinished. The monthly delivery schedule is operating, but we are marking the rule partially implemented until the report reliably represents the activity it is intended to communicate.

Customer risk

Regular delivery can create an impression of complete reporting even when activity is missing. An agency may not know which parts of the month's work remain unreconciled.

Provider compensation

The report identifies known omissions and unfinished evaluations in its opening notes. The team retains prior versions and distributes corrected reports when additional activity is recovered.

Agency compensation

Agencies can verify the reporting interval and disclosed omissions before relying on the report. They can request an updated version when missing activity affects a pending risk decision.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

Monthly delivery is operating, and the reporting owner is repairing its incomplete content with the other reporting work. Full implementation depends on completing source reconciliation and the missing evaluations and detail fields.

Target completion date

2027-03-31

Corrective actions

The reporting owner will assemble the reconciled activity into the existing human-readable layout and verify access for all necessary parties. Completion requires a full monthly report whose coverage matches the underlying records and whose corrections remain traceable to the original reporting period.

Confidence in target date (%)

75

VER-TFR-MAV: Mark Accepted Vulnerabilities¶

Rule reference · Force for this profile: MUST

Implementation status: Partially Implemented

Implementation explanation

The weekly review identifies old findings, but it does not consistently mark a vulnerability accepted when the forecast first exceeds 192 days from evaluation. Some records remain labeled as planned repairs even after that outcome is apparent. Missing or ambiguous evaluation dates also make the elapsed-time check unreliable.

Customer risk

A long-term repair can remain outside the accepted category even when completion within 192 days is already unrealistic. Agencies may not receive the explanation and continuing-exposure information associated with acceptance.

Provider compensation

The weekly meeting reviews old and supplier-dependent items and asks the engineering lead for a current forecast. Records with uncertain evaluation dates remain flagged for evidence recovery rather than receiving invented dates.

Agency compensation

Agencies can ask whether the current forecast exceeds 192 days from evaluation. They can request the acceptance rationale when the provider expects the exposure to remain beyond that threshold.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The weekly review is beginning to capture forecast-based acceptance decisions. Historical evaluation dates and long-running plans still need reconciliation.

Target completion date

2027-01-31

Corrective actions

The engineering lead will categorize findings as accepted when full mitigation or remediation is not expected within 192 days of evaluation and also check elapsed time. Acceptance testing will cover a newly forecast delay, a slipped plan, and a record whose evaluation date needs evidence recovery.

Confidence in target date (%)

90

VER-TFR-MRH: Historical Activity¶

Rule reference · Force for this profile: SHOULD

Implementation status: Not Implemented

Implementation explanation

Customers receive report files through the restricted area, with no automated JSON retrieval of recent detection and response history. The underlying log also lacks a dependable revision history for several older findings. A history interface is planned after the mandatory reporting repairs so it can expose reconciled records instead of reproducing their omissions.

Customer risk

Agencies cannot automatically retrieve a coherent recent history and may miss a changed or corrected record. Trend analysis based on individually retained files can be incomplete.

Provider compensation

The operations generalist maintains a dated report list and provides available revisions on request. Known history gaps are disclosed instead of being silently filled from memory.

Agency compensation

Agencies can retain every report revision and compare it with the provider's list. They can request a reconciled interval before using the files for historical analysis.

Corrective action plan¶

CAP status

Planned

Reason for CAP status

A modest allocation is reserved for historical retrieval after the report records are repaired. The access design and delivery capacity remain uncertain, which limits confidence in the September target.

Target completion date

2027-09-30

Corrective actions

Engineers will provide authenticated JSON retrieval of recent history with stable identifiers and explicit revisions, refreshed at least monthly. The reporting owner will verify necessary-party access and reconcile retrieved activity against the corrected source records before relying on the interface.

Confidence in target date (%)

50

VER-TFR-EVU: Evaluate Vulnerabilities Quickly¶

Rule reference · Force for this profile: SHOULD

Implementation status: Partially Implemented

Implementation explanation

Every detected finding receives an initial review within seven days, but completing the contextual evaluation often takes longer while engineers or the adviser establish the missing evidence. The log has not consistently distinguished that first review from completion of exploitability, reachability, and impact determinations. We therefore do not meet the Class B seven-day evaluation recommendation despite the weekly meeting.

Customer risk

A first review can be mistaken for a completed evaluation while exposure and impact remain uncertain. This delays both informed agency decisions and selection of an appropriate response.

Provider compensation

The weekly meeting now lists missing evidence separately and escalates potentially serious findings to the engineering lead. Urgent protective actions can begin while the full evaluation is still being completed.

Agency compensation

Agencies can request the evaluation completion date and outstanding evidence for a relevant finding. They can restrict affected use while significant contextual uncertainty remains.

Corrective action plan¶

CAP status

In Progress

Reason for CAP status

The operations log is being changed to distinguish first review from completed contextual evaluation. The team has not yet demonstrated that all required determinations finish within seven days.

Target completion date

2027-03-31

Corrective actions

The engineering lead will assign missing evidence work at intake and escalate incomplete evaluations before the seven-day limit. A complete review cycle must show that completion dates follow supported exploitability, reachability, and impact decisions across every detection source.

Confidence in target date (%)

70

VER-TFR-IRI: Internet-Reachable Incidents¶

Rule reference · Force for this profile: MAY

Implementation status: Not Applicable

Implementation explanation

We are not exercising the optional Class B treatment of internet-reachable, likely exploitable vulnerabilities above N3 as reportable incidents solely on that basis. Suspected or confirmed security incidents still go through our incident process and any independently applicable reporting duties. Our incomplete evaluation coverage is disclosed in the evaluation responses and is not treated as evidence that qualifying vulnerabilities cannot exist.

Corrective action plan¶

CAP status

Not Applicable

Reason for CAP status

The offering does not currently exercise this optional Class B vulnerability-based incident treatment. This choice leaves other incident obligations and the separately reported evaluation repairs unchanged.

VER-TFR-NRI: Non-Internet-Reachable Incidents¶

Rule reference · Force for this profile: MAY

Implementation status: Not Applicable

Implementation explanation

We are not exercising the optional Class B vulnerability-based incident treatment for non-internet-reachable, likely exploitable vulnerabilities at N5. The engineering lead still considers shared-service effects when responding to suspected incidents, subject to other applicable incident obligations. This choice does not remove the need to complete impact and reachability evaluations for the affected resources.

Corrective action plan¶

CAP status

Not Applicable

Reason for CAP status

The offering does not currently exercise the optional N5 non-internet-reachable vulnerability incident treatment. Other incident duties continue to apply independently, and the evaluation gaps remain subject to their own corrective work.