AP Cybersecurity Evidence-Based Responses: Write a Clear Recommendation (2027 Prep)

A volunteer account changes a museum's shift roster even though the museum's policy permits volunteers to view it only. A useful recommendation names the editing restriction and explains its verification, because telling the museum to improve security leaves the relevant permission untouched.

Start with the mismatch. For an AP Cybersecurity evidence-based response, identify the supplied detail supporting your claim, then explain the effect of the proposed action. Keep the action within the task's scope and preserve access that the stated policy still allows.

The original example below follows one permission problem from four short artifacts to a bounded recommendation. It is a teaching case, with no real museum records or personal information, and does not reproduce an official exam question.

Check the task before choosing a response format

College Board's current AP Cybersecurity course and exam description describes Device Security Analysis as analysis of simulated sources, with evidence and reasoning supporting conclusions. Its task-verb guidance distinguishes identifying information, explaining reasons, describing a process and determining a result.

Read the verb. In that guidance, Write means providing the proper command with the requested effect. A paragraph about a permission change cannot replace the actual command when the task requires one.

This tutorial practices explaining a recommendation. It uses a simplified application permission model, rather than a Linux file-permission task or a command-writing exercise. No particular essay structure, sentence count or score is promised.

The AP Cybersecurity Online Center connects this focused explanation to wider preparation. Use the current task instructions to decide which part of your reasoning belongs in the response, rather than pasting an entire report into every answer.

Read four artifacts from the same review

Our fictional museum uses a portal to display and maintain one shift roster, with defined Volunteer and Coordinator roles whose permissions are the focus of this review. Both roles may view. Only Coordinators may update its shift slots.

P1 is the museum's supplied policy. It states those viewing and editing rules explicitly. There is no policy exception allowing a Volunteer to make an emergency edit in this case.

A1 is the effective permission configuration at the event time. It grants the Volunteer role both view and update access to this roster, while the Coordinator role also has both permissions. Effective means these permissions actually govern the operation described here.

R1 records that vol-demo held the Volunteer role when E1 recorded shift_slot_updated for that account and slot S12, changing covered to unassigned with result success. These identifiers refer to synthetic data.

Check the event definition. In this fictional application's schema, success for shift_slot_updated means the changed value was committed to the roster, rather than merely arriving or passing an initial permission check.

These are reliable fictional artifacts. In a real investigation, checking their integrity, timing and completeness would be necessary before relying on a comparison between the policy, permissions and event.

Connect the policy conflict to a specific claim

Although P1 permits volunteers to view the roster and prohibits updates, A1 grants the role update access, creating a direct conflict with the stated policy. You can identify that mismatch without guessing anyone's motive.

Now add R1 and E1. The artifacts tie a completed change to an account holding the Volunteer role at that time, supporting the conclusion that the portal recorded an edit outside that role's policy permissions.

Keep the claim narrow. The account identifier does not identify the person at the keyboard, and a successful edit does not establish that an attacker stole credentials. No evidence here establishes malicious intent.

The changed slot creates an integrity concern because the roster's stored value was altered outside the permitted role. Whether anyone missed a shift or a museum service was disrupted remains unknown, so those consequences should not appear as observed facts.

Replace a vague suggestion with a scoped recommendation

Consider the draft suggestion: Improve security by using stronger passwords. Password strength may matter elsewhere, but the supplied defect concerns what an already signed-in Volunteer account is permitted to change.

Address that permission. An authorized application administrator should remove Volunteer update permission for this roster and enforce the Coordinator requirement on its update requests. Volunteer viewing should remain allowed, in line with P1.

That explains the mechanism. An update requested through a Volunteer session should be rejected before the roster is changed, while an authorized Coordinator can still maintain the schedule. This proposed change is limited to the operation and roles established by the case.

The OWASP Authorization Cheat Sheet supports checking authorization on every request and enforcing those checks outside the client interface. Its guidance also recommends testing authorization logic. Those principles help explain the proposed implementation, without implying that this short case supplies a complete production security design.

Explain why hiding the edit button is insufficient

A hidden button can simplify the Volunteer interface, but it does not itself enforce who may update stored data. The application must reject the unauthorized operation when it receives the request, including a request that did not come through that button.

Check the server-side decision. For this case, the trusted role associated with the authenticated session must satisfy the update rule, without accepting a role name supplied freely by the user's browser as proof of Coordinator status.

The fictional permission model has one relevant update operation and no stated delegated editors. A production application could have additional paths, objects or approved exceptions, all of which would need review. Avoid inventing those details inside this response.

Changing a password alone leaves A1's extra update permission in place. MFA also addresses authentication rather than granting the correct roster operations, so neither measure demonstrates that this authorization defect has been corrected.

Write the recommendation with its supporting evidence

Here is one possible explanation for the fictional case, written as an original worked response with no official model-answer or scoring status.

P1 allows Volunteer viewing but reserves roster updates for Coordinators. A1 grants Volunteer update permission, and R1 shows that vol-demo held that role when E1 recorded a committed change to S12. The portal therefore permitted an edit contrary to P1.

An authorized administrator should remove Volunteer update access and enforce the Coordinator requirement on the roster's update requests. This should block changes through Volunteer sessions while retaining their permitted viewing access. Verification should check the stored roster as well as the access decision.

Who operated vol-demo remains unknown. Establishing the person's identity and reason for changing the slot requires further investigation, while the proposed permission correction still needs to be implemented and tested.

Notice the connections. Each action addresses the documented permission mismatch, while the uncertainty stays attached to attribution and the unperformed verification. Adding an unsupported claim that the museum was hacked would weaken this explanation.

Specify checks that protect the required workflow

After an approved correction, a Volunteer update request should be denied and should leave the roster unchanged. A denied message alone is insufficient if the application still commits the edit. Check the resulting stored value.

Retest permitted work. A Coordinator update should succeed and persist the intended change, and a Volunteer view request should still return the permitted roster. Blocking everyone would prevent the particular edit but would also violate P1's intended workflow.

Use synthetic records in an authorized test environment and record the role, operation, expected result and actual result for each of the three proposed checks below. No system was tested. Actual results remain Pending.

Passing these checks would support the specific correction under the tested conditions. It would not establish that every account, endpoint or application operation is secure, and additional authorization paths would need their own checks.

Separate the permission correction from roster recovery

Preventing another unauthorized update does not restore S12 automatically. The application owner should preserve the relevant evidence and review the current roster against an approved source of correct scheduling information before authorizing a correction.

Avoid blind rollback. Later legitimate updates might have changed the slot again, and reverting to a value copied from an old event could overwrite valid work. The evidence here establishes the earlier committed change, not the roster's present state.

Escalate through the museum's approved process if further review identifies account compromise or wider changes. The supplied case does not establish those findings, so disabling every account or declaring a major breach would require additional justification.

Review the explanation before moving on

Read your claim beside its supporting artifact. Does P1 establish the restriction you named, and does A1 show the effective permission that conflicts with it? Check that R1 and the event definition support the particular outcome you described.

Review the action's scope. The recommendation should identify Volunteer updates as the operation to block, preserve allowed viewing and explain the Coordinator requirement. If you cannot describe how the control stops the documented operation, revisit the action.

Use the blank recommendation record (CSV) to keep an evidence detail, bounded claim, proposed action, intended effect and verification result together. The worksheet has no official scoring status, and its actual-result field should stay Pending until an authorized check has really been performed.

Continue through the AP Cybersecurity Online Center for broader study. Before finishing this case, return to the Volunteer viewing check and confirm that your proposed correction preserves the access P1 explicitly allows.

2027 preparation edition. College Board framework and OWASP guidance checked October 11, 2026. Museum, policy, roles, artifacts and worked response are original fictional teaching material, not an actual incident, official exam question or scoring rubric. Proposed changes and verification remain pending.