Our procedures (level 2 documents in the QMS) only show the latest changes. For example, if the current revision of a procedure is R03, the R03 procedure only shows what was changed when the R02 procedure was updated to R03, doesn’t show what was changed when the R01 procedure was updated to R02.

An auditor said our procedure violated ISO9001:2000 clause 4.2.3 c) “to ensure the changes and the current revision status of documents are identified.”

Was he right? What are the advantages and disadvantages of keeping the past revisions?

How did you do it?

Our procedures (level 2 documents in the QMS) only show the latest changes. For example, if the current revision of a procedure is R03, the R03 procedure only shows what was changed when the R02 procedure was updated to R03, doesn’t show what was changed when the R01 procedure was updated to R02.

An auditor said our procedure violated ISO9001:2000 clause 4.2.3 c) “to ensure the changes and the current revision status of documents are identified.”

Was he right? What are the advantages and disadvantages of keeping the past revisions?

How did you do it?Maybe, but not for that citation. How do you know the revision status of your documents? If you have a master list of your documents with the revision status, he was wrong. BTW, what you have described is not what I would do. I like to keep the complete history of the documents. It's not that difficult especially if you keep it electronically.

For example, if the current revision of a procedure is R03, the R03 procedure only shows what was changed when the R02 procedure was updated to R03, doesn’t show what was changed when the R01 procedure was updated to R02.

An auditor said our procedure violated ISO9001:2000 clause 4.2.3 c) “to ensure the changes and the current revision status of documents are identified.”

I'm pretty sure the Standard is not prescriptive in describing EXACTLY how to identify the changes.

Let's set the Standard aside for a moment and examine the business purpose underlying the clause.

Obviously, it's important that nobody tries to make product or provide service with obsolete plans. It's also important that customers and regulators are aware of the revision so they don't use obsolete plans to inspect and thus reject your product or service.

Al gives a brief clue to the next most important business purpose when he writesI like to keep the complete history of the documents.

It is important to know not everyone who has access to the new revision needs to have access to the complete history of revisions, but SOMEBODY in the organization needs to have access to assure no one tries a new revision which is a duplicate of a past version. As part of the history, noting what the changes were, I also like to include a brief comment of the business purpose served by the revision, which is completely covered in the Engineering change documents. Those Engineering Change Notices or Engineering Change Orders (different folks use different terminology to mean the documents that get circulated with the revision in the approval process and notices to affected personnel when they receive the revision) probably should be retained as either hard copies or electronic copies for the life of the program or part.

Often one revised document means other, Associated Documents, may be affected and need revision as well. I like to make notice of those changes as cross references to each other on ALL the affected documents.

As Al writes, using an electronic master system makes it all pretty easy to keep track.

“Al gives a brief clue to the next most important business purpose .”

“the complete history of revisions, but SOMEBODY in the organization needs to have access to assure no one tries a new revision which is a duplicate of a past version. As part of the history, noting what the changes were, “

These are two sentences important to my concern. I don’t get it.
I have a master list, on which only the current revision is kept. Why should the complete history of revisions be preserved? Would preserving the latest two revisions do?

The following is the content of our master list:
Doc. No & revision, Doc. Title, Effective date, owner.
This, I think, has told the employees what revision the current effective procedure is.

My question is:
When the current procedure revision is R03, who would need to know what the change was when R00 was updated to R01?

Our procedures (level 2 documents in the QMS) only show the latest changes. For example, if the current revision of a procedure is R03, the R03 procedure only shows what was changed when the R02 procedure was updated to R03, doesn’t show what was changed when the R01 procedure was updated to R02.

An auditor said our procedure violated ISO9001:2000 clause 4.2.3 c) “to ensure the changes and the current revision status of documents are identified.”

Was he right? What are the advantages and disadvantages of keeping the past revisions?

How did you do it?

Forgetting for once, the auditor's comments, document control is there in many cases for the users of the document. Depending on what the change is, few users are interested in the 'mechanics' of the change, like the master list and so forth. Users of documents mainly want to know what's changed and (possibly) why. Also, keeping a running list of changes in the actual document also makes the document bulky. Similarly, don't make them read a whole document through to find that there's been only superficial changes. A good parallel is the engineering change process. Using a document change notice (like an engineering change notice) is a good way to keep a record of the whole process of document change.:yes:

Please be careful of going through the mechanics of keeping master lists and revision numbers and recording changes. Find out what the users of documents need to know to ensure they stay up with what's going on.;)

Oh, and by the way.........the auditor was being pedantic. Did he have any examples where your system wasn't effective...............??:notme:

Andy

An auditor said our procedure violated ISO9001:2000 clause 4.2.3 c) “to ensure the changes and the current revision status of documents are identified.”
This is how we handle the changes, red/bold/italics are new requirements, strikethroughs are the old version to be removed. At the bottom of the document is the revision log. At the next revision, the red/bold/italics and strikethroughs are changed/removed as applicable.

Ours are in a database that only shows current revisions to employees. All other versions are in a secured location on a server via password protection.

Hope this helps.

Keeping a history of changes is a very important tool for continuous improvement, defect hunting, Corrective Action, Preventative Action and Root Cause Analysis activities.

“Who would need to know what the change was?” Anyone involved in these activities.

I always use a Change Notice that describes what changed and why the change was made. Often the “why the change was made” is the most important part.

The change history does not have to be kept on the document. The history can be kept in a database or other document control system such as a PDM or PLM.

I agree - the changes do not have to be with the document. However, it is much easier to control one document than many in various places/databases.

Our software system automatically arhcives all previous versions of a document.

The "reason for change" table is used however so that the users of a revised document can quickly ascertain what has been modified.

I admit to not being a fan of strike trhough's or font size/colour change. I find it lessens the "readability" of a document. But if works for a company, I won't knock it. :)

My question is:
When the current procedure revision is R03, who would need to know what the change was when R00 was updated to R01?


I guess I would ask: Why wouldn't you want to know what changes have occured during the history of this particular procedure?

I have always shown the changes on the Revision page of the particular document. It only shows what changes have occurred during the life of the document.


Coury Ferguson

The "reason for change" table is used however so that the users of a revised document can quickly ascertain what has been modified.

I admit to not being a fan of strike trhough's or font size/colour change. I find it lessens the "readability" of a document. But if works for a company, I won't knock it. :)

Actually, this has worked for 3 companies in the past 15 years.

It is somewhat a pain to change font size/color. However, the readers love it as they can quickly scan what is changed without the hassle of going to the bottom of the document then scrolling back through it to review the changes (you know how QSI works or in some cases doesn't :lol: )

I agree - the changes do not have to be with the document. However, it is much easier to control one document than many in various places/databases.

I use a database to allow a better search capability of the changes. In root cause analysis I may not know the specific document that changed just date range or subject of the change. In a database I can search by date, subject, key word,.....

Our procedures only show the latest changes. For example, if the current revision of a procedure is R03, the R03 procedure only shows what was changed when the R02 procedure was updated to R03, doesn’t show what was changed when the R01 procedure was updated to R02.

---

How did you do it?Exactly as you describe it: Only the latest changes in the current document. If anyone wants info about previous revisions, those documents are kept by yours truly. Such questions are few and far between, but I do get them.

/Claes

Exactly as you describe it: Only the latest changes in the current document. If anyone wants info about previous revisions, those documents are kept by yours truly. Such questions are few and far between, but I do get them.

/ClaesThat's good, but I understood the OP to not have maintained a complete history somewhere.

This is a "pet peeve" with me. No where is a "change history" required. I make a change in my 3-day Internal Auditor class. The presentation has over 380 pages. I change 7 different pages. The way the changes are identified to the other trainers is I send out an email outlining the changes. If it also impacts the admin staff, I change the "Instructions to Admin" and send them an email outlining the changes. That is it! If we feel there is some reason to keep the old version, we will archive it. We do this in instances where there is a major change, but for minor adjustments, the email is the only way identify what changed.

This is a "pet peeve" with me. No where is a "change history" required. I make a change in my 3-day Internal Auditor class. The presentation has over 380 pages. I change 7 different pages. The way the changes are identified to the other trainers is I send out an email outlining the changes. If it also impacts the admin staff, I change the "Instructions to Admin" and send them an email outlining the changes. That is it! If we feel there is some reason to keep the old version, we will archive it. We do this in instances where there is a major change, but for minor adjustments, the email is the only way identify what changed.

Please define minor and major changes. Can you guarantee that no minor change will ever cause major problems? Why would not want to keep a record of every change? You don’t have to keep old documents only a record of what change, when and why. To he** with ISO this just makes good business sense.

Pardon me if I get a bit hot about this. I’ve seen too many companies get burned real bad because change records are not always kept.

Please define minor and major changes. Can you guarantee that no minor change will ever cause major problems?
For the purposes of this discussion, I don't think that is relevant. The same question applies regardless of whether you keep a “change history” or not. When you make a change, the question comes into play. But I can’t see why it is important in whether you keep an old version of a document. We keep the old copies in case there is a question down the road, as to the content of the class.
Why would not want to keep a record of every change? You don’t have to keep old documents only a record of what change, when and why. To he** with ISO this just makes good business sense.
Why burden yourselves with extra paperwork? In some cases (customer drawing, etc.) I agree, it does make great sense. But most of the changes I see are minor things. We changed the wording to make it less ambiguous.
Pardon me if I get a bit hot about this. I’ve seen too many companies get burned real bad because change records are not always kept. [/QUOTE]
Likewise, I’ve seen companies make the change system so complex, folks end up making informal changes, or the change process takes so long and complicated that once a “Document Change Request” gets initiated, it takes weeks or months to get a change in place.
Don’t get me wrong. There are times when previous versions, or even some documentation as to what was changed is necessary. However, in my experience, I see this as one place where companies build monsters they can’t feed.
BTW, I also think that in some circumstances, identifying the changes through training would be sufficient.

Why should the complete history of revisions be preserved? Would preserving the latest two revisions do?
<snip>
My question is:
When the current procedure revision is R03, who would need to know what the change was when R00 was updated to R01?

This may depend on your product, but if product is returned you may want to be able to look at a document with the same revision. If there are any court cases, you would want to demonstrate the documents that controlled the process at that point in time. When improving processes, it might be worthwhile to look at the history of the process in terms of controlling documents, quality data, etc.

Just a few ideas.

Silly Girl

Yes! You get it, Silly Girl! Thanks for such a succinct reason.

Hello Darkafar:

I think your auditor's write up is a great example of why many see little value in conformtiy assessment to ISO 9001.

I suppose some one could make the case that they way 4.2.3 c) is written, that you have to identify all changes to the document since its inception. 4.2.3 c) states changes (plural). But that could also mean all of the changes that happened in the last revision.

I would want to know the business benefit of identifying ALL changes of that document since its inception.

Unless the auditor can make a good business case that it is important, I say it is a waste of time and resources to debate whether all changes or only the most recent changes need to be identified.

How many documents do we receive (in our public lives) that include all of the changes to the document? When we buy a service or tangible product, do we get documents that identify all of the changes since inception? As of right now, I can think of a single example.

Regards,

Dirk

I’d like to introduce my document system further to make the case more specific.
We have four level documents.
Level 1 is Quality Manual. I keep the whole change history because I think Quality Manual being the top level document deserves this.
Level 2 are the procedures, mainly describing the interaction between different departments. They tell what are the inputs and outputs of a process, and who is responsible, and how and where the process happens. I don’t think they are very important to the product, so I don’t want to keep the complete history of changes.
Level 3 are the work instructions. They are specific to a particular process, and explain how to transfer the inputs into outputs. I think they are important to product quality, so I keep the whole change history.
Level 4 are the control forms. Their forms are loosely controlled, and there is no change description when the revision is updated. I only tell the relevant people that a new revision control form is released, and they should use it.
In my specific case, I don’t think keep the complete change history of level 2 document is value-added. I also think the ISO9001:2000 clause 4.2.3 c) need elucidation to judge whether my documents violate it or not.

We use coversheet of all our documents which includes the brief description of the changes, ECR#, ECR date and the author's name. The coversheet has the ECR# information that we could reference if we need the detail of the changes. This is very helpful to keep track of the history of the device/documents.:rolleyes:

Our procedures (level 2 documents in the QMS) only show the latest changes. For example, if the current revision of a procedure is R03, the R03 procedure only shows what was changed when the R02 procedure was updated to R03, doesn’t show what was changed when the R01 procedure was updated to R02.

An auditor said our procedure violated ISO9001:2000 clause 4.2.3 c) “to ensure the changes and the current revision status of documents are identified.”

Was he right? What are the advantages and disadvantages of keeping the past revisions?

How did you do it?


Sorry to dig up an old discussion but I was searching for "Master List" to see what others are doing and if they are still used under ISO 9001:2000. As far as your audit finding goes....I do exactly what you do: Only show the current changes in the current revision. But, all past changes are with the past revision in archived electronic files. I've never had a problem with this method and it is not violating 4.2.3 c. JMO and experience for the last 8 years. ;)

The reason for only showing the current revisions in the document is it can become quite lengthy and confusing. People(including the registrar) seem to look at the change record and think they are looking at the actual procedure even though it is clearly marked "Change Record". This can lead one to not follow the documented process and cause an actual finding. Past information, unless specifically requested, is unnecessary in current revisions. JMHO. ;)

<snip>

The reason for only showing the current revisions in the document is it can become quite lengthy and confusing. People(including the registrar) seem to look at the change record and think they are looking at the actual procedure even though it is clearly marked "Change Record". This can lead one to not follow the documented process and cause an actual finding. Past information, unless specifically requested, is unnecessary in current revisions. JMHO. ;)

We keep information about all changes to all documents in our document database...this lets us know what happened when without having to load down the documents themselves with tons of historical information. Databases are ideal for this kind of thing!

Silly Girl

I just pull up the archived document to see past changes. Similar to looking up in a database. Curious what "database" you chose to use?

Curious what "database" you chose to use?

It's a homebrew Access database. It records the document information including doc number, title, owner, review due date, current revision and revision date, affected departments. Retention information is recorded for quality records. The database also records the change history of each document. It also gives us a cross reference that shows which documents refer to which other documents. It emails out notifications weekly to inform people about documents that have changed, and also lets the owner know that it is time to review their documents... works pretty well for us.

Silly Girl

It's a homebrew Access database. It records the document information including doc number, title, owner, review due date, current revision and revision date, affected departments. Retention information is recorded for quality records. The database also records the change history of each document. It also gives us a cross reference that shows which documents refer to which other documents. It emails out notifications weekly to inform people about documents that have changed, and also lets the owner know that it is time to review their documents... works pretty well for us.

Silly Girl

Nice. Sounds like a winner! Homebrews always seem to work best. :applause:
Let me know if you ever plan to share the structure for others. :) Can't say it would work for us due to limitations in the company but someone might benefit.

Let me know if you ever plan to share the structure for others. :) Can't say it would work for us due to limitations in the company but someone might benefit.

If people are interested I might consider it. The biggest problem is that it is so tied into data automations within our company, I would have to do some surgery to make it usable outside our network. I must admit, I have often wondered if I could make a living just making homebrews for different organizations!

Silly Girl

Our Documents are all on the company intranet - I had the IT department "build" in a revision history tool that allows me to note changes as well as view the archived file when the new document replaces the old.
Screen sample attached.

Maybe, but not for that citation. How do you know the revision status of your documents? If you have a master list of your documents with the revision status, he was wrong. BTW, what you have described is not what I would do. I like to keep the complete history of the documents. It's not that difficult especially if you keep it electronically.

i am completely agree with you