A transit mobile app adds in-app payments, but the team never revisits the threat model created for the earlier schedule-only release. What is required?
Select an answer to reveal the explanation.
Short Explanation
Payments change the game: money, cards, and greedier attackers walk in. An old schedule-only threat model is a museum piece once you take dollars. Refresh the model when the architecture grows new crown jewels.
Full Explanation
When a transit mobile app adds in-app payments, the threat model must be updated to reflect new assets, data flows, trust boundaries, and abuse cases. Schedule-only designs typically did not center payment card data, payment processors, refund fraud, or account takeover for financial gain; those changes alter risk materially. Archiving the old model as final because 'payments do not change trust boundaries' is factually wrong for most architectures. Assuming PCI or other obligations automatically rewrite the engineering threat model without involvement leaves design gaps between compliance checklists and actual abuse paths. Deleting payment features only after launch when threats appear reacts too late and skips prior analysis that should have shaped controls. Exam caveat: CISSP expects threat models to evolve with the system; major feature shifts that add valuable assets require re-analysis. Operational check: reopen the threat model for payment flows, tokenization, mobile storage, API authorization, and fraud scenarios; align mitigations with payment security requirements; and retest before enabling payments in production. Schedule periodic model reviews tied to release trains so future feature growth does not silently outpace security analysis.