I looked at the link @Willl provided, and there are some interesting comments there.
If we take Scrum, as one of the Agile project models/frameworks, it has structure, artifacts (documentation) and so on, so if your company declares in steering documents that you should for certain types of projects use Scrum, it would suffice either link to a generic model or document your version.
As the best answer to @Willl's provided link above, an auditor asks:
- What are you doing?
- How do you know what you should be doing?
- And then there should be some mathching documentation.
If a developer/tester is working on something, it should be documented in the Scrum Product Backlog on a high level, the Scrum Sprint Backlog on an intermediate level (as of working in the current Sprint) and also be on more detailed level, either in form of post-its in the Scrum Planning room or even written as tasks in for example Jira/Confluence. If you really follow the Scrum methodology it should also be part of the Scrum Burndown chart.
Thereby, you have documentation on all levels to satisfy ISO9001, so if you have any arguments of why Scrum can't coexist with ISO9001, you are probably not using Scrum (Agile) as it was intended.
Also, Scrum/Agile must not be an argument for not documenting requirements and other important documentation.