PENTESTY · EDITORIAL ANALYSIS · · 4 min read
Margaret Hamilton’s legacy raises a practical question: how should your system fail?
Define what must stop, what may continue and which controls must remain active when a dependency stops responding.
By Pentesty
The confirmed context and this analysis’s proposal
On October 7, 2026, MIT reported that Margaret Hamilton died on September 30, aged 90. She led software teams for the Apollo program. In 2003, NASA recognized contributions by Hamilton and her team, including processing priorities and testing. This analysis proposes applying that concern for failure to present-day enterprise software decisions.
Write a contract for each important failure
Consider a portal accepting orders while an external service checks permissions. The team needs to decide beforehand whether an outage blocks the operation, permits viewing only or accepts a pending request. The answer depends on business impact and the authorization required. An order that proceeds without an access check may turn apparent availability into data exposure.
Choose a significant workflow and document the dependency, failure condition and permitted outcome. Include an owner for the decision and a criterion for returning to normal operation. This contract gives product, engineering and security teams something concrete to discuss, without relying on the interpretation of whoever happens to handle the incident.
Degraded operation still needs permission boundaries
An operational alternative should maintain the access boundaries defined for the task. Reviewing OWASP application risks helps select checks that remain necessary during a failure. During exercises, use test accounts with different permissions and fictional data to observe both allowed and denied decisions.
- Identity: the test session remains associated with the correct user after recovery.
- Authorization: unavailability does not grant an operation previously denied to that account.
- Data: error messages and logs do not expose information beyond what is necessary.
- Integrity: repeating an interrupted request does not cause an improper business change.
Test one hypothesis at a time and define when to stop
Start in an authorized, representative environment with a narrow hypothesis, such as a delayed integration response. Agree on duration, impact boundaries, supervision and a stop mechanism. Observe the complete request path, because a screen that appears to have recovered may conceal pending work at another stage.
The exercise needs to end with business validation. Check that accepted orders completed once, denied requests remained denied and pending work has an owner. Then restore the original condition and check again. Include these results in the evidence from a technical assessment, with clear boundaries around what was actually tested.
Turn the observation into a release decision
A useful record includes the version, scenario, expected outcome, observed outcome and enough evidence for someone else to repeat the check. Distinguish a known limitation from a failed control. If the change requires accepting risk, identify who can approve that decision and when it will be reviewed.
Pentesty’s analysis is that anticipating failure behavior improves the questions asked before release. The exercise covers selected scenarios; new dependencies, permission changes and configuration differences may require another assessment. Connect the procedure to the people responsible for operation and recovery so the evidence remains usable after delivery.
Also define how a temporary exception ends. An integration disabled to work around a failure may remain outside the workflow after recovery. Record the deadline, the person authorized to close the exception and the check demonstrating a return to the approved design. Include this condition in change follow-up so removing a temporary workaround does not depend solely on someone remembering it.
Frequently asked questions
How do availability failures relate to security?
A failure can change access decisions, expose errors or leave operations incomplete. Testing should observe those concrete effects and the authorized behavior for that workflow.
Do we need to shut down a production service?
An initial exercise can use simulation in an authorized, representative environment. Any production assessment needs a scope, boundaries, owners and stopping criteria agreed beforehand.
How should we choose the first scenario?
Select an important business workflow with an external dependency and a verifiable outcome. Describe a specific failure condition and agree on the response that will count as acceptable.
What evidence should remain after testing?
The version, scenario conditions, authorization decisions, business outcome and recovery confirmation. Limit records to what is needed and assign owners to outstanding work.
Sources and references
- MIT News: obituary published October 7, 2026
- NASA: recognition of Hamilton and her team, September 3, 2003
Original Pentesty analysis, published October 15, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.