How to handle a change in acceptance criteria for a user story?

I'm interested to find out how people deal with changes to acceptance criteria of user stories on a process level.

Example:

You write a user story with acceptance criteria for feature XYZ. That user story gets implemented in a sprint of release 1.0. Some time later for the 1.2 release the product owner wants the acceptance criteria to be different (e.g. 1 minute timeout instead of 30 seconds).

How do you handle this change? How does it change the status of your original user story? We're using JIRA/JIRA Agile and I'd be specifically interested in hearing if you e.g. re-open your closed user stories and work on them in a new Sprint.

We're using Confluence to write our product specifications and the user stories in the PS are loaded directly from JIRA via a query. If one was to change acceptance criteria of the original user story and reopen it - how would one ensure that the product specification for version 1.0 wouldn't change?

EDIT:

I need to add some more information about our process: every user story has as well as the acceptance criteria some steps which can be used to test these criteria. These steps are used to generate a verification/test protocol which is used to check that all product specifications have been implemented properly.

Now this means a change to the user story would directly affect even already reviewed and signed off product specifications and test protocols since data is loaded via the jira query. I guess that this might not be an adequate way to pull the content into Confluence, something more permanent seems advisable.

Even if we weren't using these direct/dynamic queries, the question is still valid: how does a change in requirements/acceptance criteria affect the user story?

Thank you everyone for your answers. We have since found a way suitable for us to handle changes to user stories.

What we ended up with are the following principles/steps:

• Once a software version has been released all user stories which are part of the product specification for that release must not be changed anymore
• If the acceptance criteria of the user story should be changed after the release, a change request is filed and linked against the story
• The change request is then processed - in the course of it the affected user story is cloned, adapted to the changed acceptance criteria and then added to the product specification for the next release while the old user story is removed
• The new user story can now be implemented during a sprint

This way we have a product specification for v1.0 which contains the unchanged user story and a product specification for v2.0 which contains the updated user story.

The important fact is that years later you could pick up the product specification for any version and test it against the acceptance criteria and still get a PASS. This wouldn't be the case if the original user story had been modified.

I hope I managed to explain this in sufficient clarity. Please let me know if I need to elaborate on any parts of the solution.