A clustered index must be re-ordered when it is updated. That means the whole index is basically reorganized, and that is why it's expensive. A primary key (PK) is usually a clustered index but not necessarilly always, however, I would advise that a PK should be clustered.

But also, a custered index is not necessarilly always a primary key. Columns that regulary get updated should preferrably NOT be part of a clustered index, especially in cases where the table row count grows large. If a column (or more), other than the PK, must be part of an index, then make the index non-clustered where possible. If the table however will always stay relatively small in rows count, then updating clustered indexes shouldn't have that much of a performance impact. However, each scenario is unique, and is heavily dependant on how many times the update statement is called (think concurrency on a busy server).

Also, what GilaMonster said is true. The query may look expensive, but the percentage is relative to the other steps in the batch/query. It only tells you which part cost you the most.

Somewhere in the query/batch there is most likely an update statement that updates the value of the PK column(s) of a table, or at least a column (or more) that is part of a clustered index. If the index is not a primary key, consider changing the index to a non-clustered index. Otherwise, if you can determine that the index is not used very much or not at all, then you can consider removing the index entirely.

Hope this helped 🙂