← SWIFT: decisões de suporte e projetos bancários
10 / 10 · 60 MIN

Oficina: evidência de mudança e aceitação operacional

Ligar ensaios ao candidato, rever âmbito de segurança, calcular limites de rollback e preparar uma passagem à operação com responsabilidades claras.

Associar evidência ao candidato

Um pacote de entrega pode conter muitos testes positivos e ainda não demonstrar a alteração proposta. No exercício, o candidato dr-7 pertence ao ambiente QUALIFICATION, âmbito fp-2 e conjunto de controlos scope-3. O gate local compara esses quatro atributos com o relatório e exige observed=true. Alterar um atributo recusa a correspondência. Esta regra conservadora é inventada para praticar rastreabilidade, não é um formato prescrito pela Swift. Um ensaio apenas agendado continua pendente. Antes da reunião, o PM deve conseguir apontar o artefacto efetivamente executado, as diferenças face ao candidato e a evidência que ainda falta produzir.

Rever arquitetura e responsabilidades

Uma migração pode retirar servidores locais e criar novos percursos de acesso ou dependências de terceiros. Preparar um desenho antes e depois, identificar componentes, operadores e responsabilidades que mudam e pedir análise do âmbito de controlos. A página pública CSP orienta a identificação da arquitetura e o mapeamento dos controlos aplicáveis. O laboratório não determina o tipo de arquitetura de uma instituição nem implementa uma checklist CSCF. Obter a edição e orientação de produto adequadas exige trabalho próprio. O PM coordena a produção dessa informação e regista dependências; um contrato comercial ou um número menor de servidores não substitui a análise.

Separar preparação e avaliação independente

A equipa de implementação pode recolher evidência e explicar decisões, mantendo a avaliação independente com um assessor elegível. Não basta mudar o título de quem desenhou o controlo. Para reutilizar uma avaliação anterior, a FAQ pública exige concordância do assessor, ausência de mudança significativa invalidante e cobertura dos controlos novos ou alterados; a mesma avaliação não pode ser reutilizada mais de uma vez. A função do exercício apenas representa esses pré-requisitos. Um resultado verdadeiro não certifica conformidade nem autoriza atestação. O pacote deve distinguir factos observados, conclusões propostas e decisões que competem ao processo de avaliação efetivo.

Calcular o momento de decidir

O caso local tem fecho ao minuto quarenta, rollback de doze minutos, reconciliação de oito e margem de cinco. O último início que cabe é quinze. Ao minuto dezasseis, manter esses pressupostos prevê fecho em quarenta e um. Não se recupera tempo alterando o timestamp ou omitindo silenciosamente reconciliação. A equipa deve escalar o desvio e apresentar impacto e opções à autoridade definida. Estes valores não são prazos Swift. O exercício serve para ensaiar uma conversa difícil fora de horas: distinguir o que é tecnicamente possível, o que cabe na janela e o que precisa de nova decisão.

Conservar evidência útil e proporcional

O guião pede ambiente, versão, hora, identificador de correlação, resultado observado e questões abertas. Um erro sanitizado pode apoiar diagnóstico sem divulgar um token ou password. Um hash permite comparar bytes com a referência usada, mas não prova que o ensaio ocorreu no ambiente declarado nem que uma pessoa independente o aceitou. Se houve restauro local, reconciliar efeitos já produzidos noutros sistemas antes de decidir reprocessamento. O gate de recuperação mantém aceitação do responsável como condição distinta. Um teste verde é informação para a decisão; não escreve uma aprovação em nome de quem ainda não a deu.

Praticar uma entrega utilizável

A oficina abaixo dura 45 minutos e distribui papéis de APS, PM e responsável funcional. Primeiro analisar a versão divergente e as condições de recuperação; depois introduzir o atraso no limite de rollback. Preparar um resumo de decisão em inglês com observação, impacto, opções, responsável e próxima atualização. Nos últimos dez minutos, outra pessoa tenta localizar os artefactos e repetir o diagnóstico usando apenas o pacote. Registar dificuldades e corrigir o runbook. Se o aluno fizer tudo sozinho, classificar como prática individual. A publicação deste material não demonstra uma oficina realizada, competência de um turno nem aceitação operacional de uma instituição.

DR original workshop / Oficina original DR: 45 minutes
Fictional maintenance only. No Swift traffic, real change or attestation.
Manutenção fictícia. Sem tráfego Swift, mudança real ou atestação.

0-10 min: Evidence / Evidência
Candidate: dr-7, QUALIFICATION, fp-2, scope-3.
Report: dr-6, QUALIFICATION, fp-1, scope-3, observed=true.
Identify build and footprint gaps; do not relabel the report.
Identificar diferenças de build e âmbito; não alterar os rótulos do relatório.

10-20 min: Recovery / Recuperação
Process up at minute 10; functional recovery forecast at minute 25.
Local functional target: minute 15. State the gap explicitly.
Processo ativo em 10; recuperação prevista em 25; alvo funcional 15.
Indicar explicitamente a lacuna face ao alvo.

20-35 min: Decision / Decisão
Deadline 40; rollback 12; reconciliation 8; reserve 5.
Latest rollback start = 15. At minute 16 forecast completion = 41.
Último início = 15. Ao minuto 16, fecho previsto = 41.
English note:
Observed: candidate evidence mismatch; rollback decision is late.
Impact: current recovery assumptions exceed the agreed window.
Decision needed: accountable owner to choose an authorized response.
Evidence needed: candidate-specific results and revised recovery forecast.
Next update: name a responsible role and specific time.

35-45 min: Handover / Passagem à operação
Another participant locates version, outcomes, runbook and escalation route.
Outro participante localiza versão, resultados, runbook e escalada.
Record usability failures and unresolved assumptions.
Registar falhas de utilização e pressupostos por resolver.
Solo practice is self-review, not independent acceptance.
Prática individual é autoavaliação, não aceitação independente.
Deliver expected/observed evidence without credentials or real customer data.
Entregar evidência esperada/observada sem credenciais ou dados reais de clientes.
NA PRÁTICA

Caso: dr-6 passou no ensaio, mas dr-7 altera o acesso. Identificar a diferença, atribuir avaliação do impacto e obter evidência aplicável antes da aceitação.

Armadilhas comuns

Relatório antigo com data nova; autoavaliação chamada independente; hash como prova de verdade; rollback sem reconciliação; presença como autonomia.

Tópicos relacionados: Estados, reconciliação e recuperação sem duplicar · Segurança, âmbito e evidência independente · Continuidade e passagem à operação

Leva esta ideia contigo

Aceitar uma entrega exige evidência aplicável, condições funcionais e autoridade identificada; a oficina permite praticar sem atribuir conformidade externa.

Criar conta

Referência: NIST SP 800-34 Rev. 1: Contingency Planning Guide · DR Swift knowledge assessment2026.10; independent professional curriculum

SWIFT® é uma marca registada de S.W.I.F.T. SC. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Swift. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.