B6.9 Repository demonstrates that all access requests result in a response of acceptance or rejection.
Eventually a request must succeed or fail, and there must be limits on how long it takes for the user to know this. Access logs are the simplest way to demonstrate response time, even if the repository does not retain this information for long. However, a repository can demonstrate compliance if it can show that all failed requests result in an error log of some sort, and that requests are bounded in duration in some way.
Evidence: System design documents; work instructions (if DIPs involve manual processing); process walkthroughs; logs of orders and DIP production.
We capture this type of information in two places.
One location is the standard Apache httpd access and error logs. This records access attempts, failures, and much more information. These logs grow quite large, and we keep only a limited history for any length of time.
The other location is what we call our "order history" database. This database contains very detailed records of accepted requests, and we keep records indefinitely. Because our delivery system evolves over time, older records contain less information that newer records; for example, records that predate MyData accounts and profiles do not contain this information.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.