The things have to be done for ISO9001:
- set up processes.
- stick to the processes.
- prove that you sticked to the processes.
- adjust the processes.
The most additional time is spent writing good processes. It is possible to leave this to other people. There is a risk that testing might be described in undesirable way. Input and review should not cost more than 1 working day, unless there is a long process compliant with the way of working of the customer.
My suggestion for processes is Keep it simple.
Sticking to the processes takes a small additional time in an Agile environment. For a Waterfall environment it is hard to determine. It is important to add time for ISO9001 in the planning.
Proving that you sticked to the test processes can take 1 day. If the administration is not uptodate, then it will take more days.
Adjusting the processes does not happen often. Also in this case Input and review should not cost more than 1 working day, unless there is a long process compliant with the way of working of the customer.
The formal processes should impact testing in an achievable and helpful way. I would describe the current process and add some small improvements after talking with other people.
ISO9001 is not a full time job. If this is the case, then things have to be fixed. It is important to determine your scope of work for ISO9001.
“E.g. we try to work in a more agile work. So there is no detailed functional specification document any more.”
In this example I wanted to highlight the use of detailed names for documents.
Let me project this to your situation.
Suppose my firm uses a detailed functional specification document as stated in the process. After a while this document is replaced by a high level functional document and a technical document, because the customer did not like all the technical terms.
At this moment my firm does not adhere to the process: the wrong documents are used. It is better to use a more abstract term like design documentations in the process description.