Pix: turn requirements into operational evidence
A readiness calendar becomes actionable when each delivery has an accountable owner and proof that it works. Structure an assessment connecting technical decisions, providers and operations.
Leer en portuguésBy Pentesty
The confirmed calendar and the scope decision
The BCB’s Volume II 6.01, dated November 9, 2026, sets February 7, 2027 for section 1.1 items a, b, e, f and g, and March 8 for c and d. Section 5.5 specifies SPB-Web for certificate deactivation from November 16, 2026. These requirements address Pix scheme participants.
The analysis below is Pentesty’s operational proposal. Before using it, the institution should determine which services, entities and responsibilities belong in its assessment. Record who approves that boundary, which interpretations need confirmation and which document supports each decision. A testing plan does not replace this determination of applicability or establish it on the institution’s behalf.
Start with the decision that evidence must support
Select a representative workflow, such as an authorized change to a laboratory integration. Describe the expected outcome before looking at the available tool. Who can request the change? Who can authorize it? What information enables the operator to stop execution? A worksheet with verifiable answers can reveal dependencies that a product inventory may leave hidden.
Associate each decision with an accountable owner and a verifiable artifact. This might be an exported configuration, a recorded approval or the result of a controlled attempt. Retain the time, environment, version and limitations. Keep secrets out of the assessment package: a key identifier or vault reference is usually more useful to reviewers than a credential reproduced in a report.
Define the expected result before running the test
Prepare one permitted case and one that should be refused. Use synthetic accounts and data, written authorization and a stop condition. If an operator needs an exception to complete the test, record the exception and its expiry. The result should show observed behavior, including any departure from the approved design, rather than simply recording that a test ran.
An isolated test answers a limited question. To avoid overly broad conclusions, describe the path actually exercised: identity, application, dependency and destination. Repeat the case after a relevant change and compare results. Evidence of refusal should distinguish a working policy from a connectivity error that merely prevented the test from reaching the decision point.
Bring the provider and operations into the same exercise
Choose a handoff and simulate delivery of an alert or intervention request. Confirm who receives it, how they acknowledge the case and who can authorize the next step. A signed contract does not demonstrate that the person on duty can locate the procedure or reach an absent decision maker when the exercise requires an immediate response.
Use the discussion of SOC coverage to ask what was actually observed. Pair the exercise with an assessment of technical team continuity, checking whether another operator can reproduce the decision with the available material. These tests complement the documentation selected for the scope; they do not certify an entire institution or all its dependencies.
Close the loop with explicit unresolved items
Organize results into accepted deliveries, reproduced failures and unanswered questions. Each failure needs an owner, a next action and a condition for retesting. For an interpretation issue, record the question and where an authoritative answer is expected to come from. Avoid turning an informal conversation into a definitive technical requirement without a verifiable basis.
Management should be able to understand what was demonstrated and what remains unproven. A small package linking each decision to its evidence is more useful than screenshots without context. Preserve negative results as well: they explain why a delivery should not yet be accepted, what work remains and which assumptions the team needs to revisit.
Frequently asked questions
Does this plan automatically apply to every company?
No. The organization should determine applicability to its own role before using this operational plan. The proposed assessment uses an approved scope and documented limitations.
Is a screenshot sufficient evidence?
It may help, but it needs context: origin, time, environment, expected result and accountable owner. Include information that supports repeatable verification without exposing credentials.
How should an unresolved interpretation be handled?
Record the question, who must answer it and the decision that depends on it. Keep the issue visible until a verifiable basis is available to close it.
When should the exercise be repeated?
Agree on triggers with the service owner. Changes affecting the tested path or operator authority justify reviewing the cases and repeating the relevant tests.
Sources and references
Original Pentesty analysis, published November 13, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.